[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5

2020-11-16 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1898547

Title:
  neutron-linuxbridge-agent fails to start with iptables 1.8.5

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in iptables package in Ubuntu:
  Fix Released
Status in neutron package in Ubuntu:
  Invalid
Status in iptables source package in Groovy:
  Fix Released
Status in neutron source package in Groovy:
  Invalid
Status in iptables source package in Hirsute:
  Fix Released
Status in neutron source package in Hirsute:
  Invalid

Bug description:
  [Impact]

  With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start.

  The log file shows many errors like:

  2020-10-05 10:20:37.998 551 ERROR
  neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr:
  iptables-restore: line 29 failed

  This can be demonstrated with a simple test case:

  iptables-restore 

[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15

2020-10-13 Thread Andrew Cloke
** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1899621

Title:
  [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on
  z15

Status in Ubuntu on IBM z Systems:
  New
Status in zlib package in Ubuntu:
  New

Bug description:
  Description:   zlib: inflateSyncPoint() returns an incorrect result on z15
  Symptom:   Certain rsync builds fail with "error in rsync protocol data
 stream" on z15.
  Problem:   inflateSyncPoint() does not take into account the hardware
 compression state and returns an incorrect result.
  Solution:  Make inflateSyncPoint() fail if the hardware compression is on.
 The hardware does not provide enough information in order to
 implement this function.
  Reproduction:  z15 only: printf 1 >1 && rsync -z 1 2

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations

2020-08-18 Thread Andrew Cloke
@heinz-werner_seeck, this has been scheduled into the relevant team's current 
2-weekly cycle. As usual we'll share progress and updates in this ticket.
Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1882494

Title:
  [UBUNTU 20.04] zlib not working on all s390x systems configurations

Status in Ubuntu on IBM z Systems:
  Triaged
Status in zlib package in Ubuntu:
  New
Status in zlib source package in Eoan:
  Won't Fix
Status in zlib source package in Focal:
  New
Status in zlib source package in Groovy:
  New

Bug description:
  Pull request (https://github.com/madler/zlib/pull/410) and tagged
  https://github.com/iii-i/zlib/tree/dfltcc-20200511.

  The new code contains the following improvements:
  * Added support for switching between software and hardware compression.
  * Added --dfltcc configure flag (the old way of building it still works).

  Switching between software and hardware compression is not simply a
  nice-to-have feature, but is actually required by Java - that's why we
  are requesting an update.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1873961] Re: tc filter show tcp_flags wrong mask value

2020-08-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1873961

Title:
  tc filter show tcp_flags wrong mask value

Status in The Ubuntu-power-systems project:
  Fix Released
Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Fix Released

Bug description:
  [SRU Justification]

  Impact: The tc command does not show the correct values for tcp_flags
  (and ip_tos) on filter rules. This might break other scripts parsing
  that output but at least confuses users.

  Fix: Backport of "tc: fix bugs for tcp_flags and ip_attr hex output"
  from upstream iproute2.

  Testcase:
  tc qdisc add dev lo ingress
  tc filter add dev lo parent : prio 3 proto ip flower ip_tos 0x8/32
  tc filter add dev lo parent : prio 5 proto ip flower ip_proto tcp \
   tcp_flags 0x909/f00

  tc filter show dev lo parent :

  filter protocol ip pref 3 flower chain 0
  filter protocol ip pref 3 flower chain 0 handle 0x1
    eth_type ipv4
    ip_tos a9606c10 <-- bad, should be 0x8/32
    not_in_hw
  filter protocol ip pref 5 flower chain 0
  filter protocol ip pref 5 flower chain 0 handle 0x1
    eth_type ipv4
    ip_proto tcp
    tcp_flags 909909 <-- bad, should be 0x909/f00
    not_in_hw

  Note that the ip_tos value in the -j[son] output is correct, while the 
tcp_flags value is
  is incorrect in both cases.

  Risk of Regression:
  Low: Usually scripts would use the json output and that has at least the ip 
output correct. And the values shown in the bad case seem to be little useful. 
So it seems unlikely anybody relied on them. But cannot completely be ruled out.

  === Original description ===

  ---Problem Description---
  Problem Descriptions
  "tc" utility does not show correct TC rule's tcp_flags mask correctly in 
current "iproute2" package shipped on Genesis.
  # dpkg -l |grep iproute2
  ii  iproute2  4.15.0-2ubuntu1  ppc64el  networking and traffic control 
tools

  ---Steps to Reproduce---
   Steps to reproduce the problem:
  1) Add a tc rule to the testing VF (i.e. p0v2_r):
  # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1  
flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2  
skip_sw action mirred egress redirect dev p0v0_r

  2) Validate the added TC rule:
  # tc filter show dev p0v2_r root
  filter protocol ip pref 5 flower chain 1
  filter protocol ip pref 5 flower chain 1 handle 0x1
    src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff
    eth_type ipv4
    ip_proto tcp
    tcp_flags 22   /* <--- Wrong */
    skip_sw
    in_hw
  action order 1: mirred (Egress Redirect to device p0v0_r) stolen

  3) If we add the tcp_flags using explicit mask 0x7:
  # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1  
flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 
 skip_sw action mirred egress redirect dev p0v0_r

  After that, using "tc filter show dev p0v2_r root" to verify, we still
  see the same output (tcp_flags 22) as shown in 2) above, which is
  wrong.

  Userspace tool common name: tc

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

  Userspace package: iproute2

  ==
  Fixes:
  There are 2 patches to fix the issue:
  patch 1:
  commit b85076cd74e77538918d35992b1a9cd17ff86af8
  Author: Stephen Hemminger 
  Date:   Tue Sep 11 08:29:33 2018 -0700
  lib: introduce print_nl
  Common pattern in iproute commands is to print a line seperator
  in non-json mode. Make that a simple function.
  /* This patch declares global variable "const char *_SL_ = "\n";" in 
lib/utils.c to be used by 2nd patch */

  patch 2:
  commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc
  Author: Keara Leibovitz 
  Date:   Thu Jul 26 09:45:30 2018 -0400
  tc: fix bugs for tcp_flags and ip_attr hex output
  Fix hex output for both the ip_attr and tcp_flags print functions.

  With the above 2 patches pull in, the new "tc" utility will show the correct 
tcp_flags mask:
  # tc filter show dev p0v2 root
  filter protocol ip pref 5 flower chain 1
  filter protocol ip pref 5 flower chain 1 handle 0x1
    src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff
    eth_type ipv4
    ip_proto tcp
    tcp_flags 0x2/7   /* <--- Correct */
    skip_sw
    in_hw
  action order 1: mirred (Egress Redirect to device p0v0_r) stolen

  
  This bug affects tc in Ubuntu 18.04.1 stock image.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1873961] Re: tc filter show tcp_flags wrong mask value

2020-05-29 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1873961

Title:
  tc filter show tcp_flags wrong mask value

Status in The Ubuntu-power-systems project:
  Triaged
Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Triaged

Bug description:
  ---Problem Description---
  Problem Descriptions
  "tc" utility does not show correct TC rule's tcp_flags mask correctly in 
current "iproute2" package shipped on Genesis.
  # dpkg -l |grep iproute2
  ii  iproute2  4.15.0-2ubuntu1  ppc64el  networking and traffic control 
tools

   
  ---Steps to Reproduce---
   Steps to reproduce the problem:
  1) Add a tc rule to the testing VF (i.e. p0v2_r):
  # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1  
flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2  
skip_sw action mirred egress redirect dev p0v0_r
   
  2) Validate the added TC rule:
  # tc filter show dev p0v2_r root
  filter protocol ip pref 5 flower chain 1
  filter protocol ip pref 5 flower chain 1 handle 0x1
src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff
eth_type ipv4
ip_proto tcp
tcp_flags 22   /* <--- Wrong */
skip_sw
in_hw
  action order 1: mirred (Egress Redirect to device p0v0_r) stolen
   
  3) If we add the tcp_flags using explicit mask 0x7:
  # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1  
flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 
 skip_sw action mirred egress redirect dev p0v0_r
   
  After that, using "tc filter show dev p0v2_r root" to verify, we still see 
the same output (tcp_flags 22) as shown in 2) above, which is wrong.
   
  Userspace tool common name: tc 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace package: iproute2

  ==
  Fixes:
  There are 2 patches to fix the issue:
  patch 1:
  commit b85076cd74e77538918d35992b1a9cd17ff86af8
  Author: Stephen Hemminger 
  Date:   Tue Sep 11 08:29:33 2018 -0700
  lib: introduce print_nl
  Common pattern in iproute commands is to print a line seperator
  in non-json mode. Make that a simple function.
  /* This patch declares global variable "const char *_SL_ = "\n";" in 
lib/utils.c to be used by 2nd patch */
   
  patch 2:
  commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc
  Author: Keara Leibovitz 
  Date:   Thu Jul 26 09:45:30 2018 -0400
  tc: fix bugs for tcp_flags and ip_attr hex output
  Fix hex output for both the ip_attr and tcp_flags print functions.
   
  With the above 2 patches pull in, the new "tc" utility will show the correct 
tcp_flags mask:
  # tc filter show dev p0v2 root
  filter protocol ip pref 5 flower chain 1
  filter protocol ip pref 5 flower chain 1 handle 0x1
src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff
eth_type ipv4
ip_proto tcp
tcp_flags 0x2/7   /* <--- Correct */
skip_sw
in_hw
  action order 1: mirred (Egress Redirect to device p0v0_r) stolen

  
  This bug affects tc in Ubuntu 18.04.1 stock image.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock

2019-09-04 Thread Andrew Cloke
** No longer affects: util-linux (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1837443

Title:
  [Power9][Witherspoon dd2.3] unable to set hwclock

Status in The Ubuntu-power-systems project:
  Fix Released

Bug description:
  On the upgraded witherspoon Power9 system we are unable to set
  hwclock.

  ubuntu@bobone:~$ uname -a 
  Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
  ubuntu@bobone:~$ cat /etc/issue
  Ubuntu 19.04 \n \l

  ubuntu@bobone:~$ date 
  Mon Jul 22 18:25:04 UTC 2019
  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock
  2019-07-22 18:25:26.799805+00:00
  ubuntu@bobone:~$ 

  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock --verbose
  hwclock from util-linux 2.33.1
  System Time: 1563820048.938797
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1101096600 seconds after 1969
  Last calibration done at 1101096600 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ioctl(4, RTC_UIE_ON, 0): Invalid argument
  Waiting in loop for time from /dev/rtc0 to change
  ...got clock tick
  Time read from Hardware Clock: 2019/07/22 18:27:29
  Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969
  Time since last adjustment is 462723449 seconds
  Calculated Hardware Clock drift is 0.00 seconds
  2019-07-22 18:27:28.877732+00:00
  ubuntu@bobone:~$

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

2019-09-03 Thread Andrew Cloke
** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

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

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1842436

Title:
  [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

Status in Ubuntu on IBM z Systems:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  efault blocksize of a file-system seems to be dependent on the volume-size.
  Big volume (at least ext4) does have 4k blk-size, even the underlaying devise 
with a smaller phyiscal blk-size.

  The patch, avoiding define mixed-sized volume groups is now upstream
  in the master branch of LVM2
  
https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b

  Using this patch within the distribution is for sanity reasons.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1842284] Re: initramfs does not copy ehci-platform

2019-09-03 Thread Andrew Cloke
** Changed in: initramfs-tools (Ubuntu)
   Status: Invalid => Confirmed

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842284

Title:
  initramfs does not copy ehci-platform

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  New

Bug description:
  [Impact]
  If you install Ubuntu onto USB storage behind a Platform USB host controller, 
it will not be able to boot because the generated initramfs will not include 
the host controller driver.

  [Test Case]
  Install to a USB stick attached to platform USB controller and reboot. 
Booting will fail because it will be unable to find the root file system.

  [Regression Risk]
  Driver is only loaded when system requires ehci-platform, minimizing the 
impact to all other systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1842284/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock

2019-09-02 Thread Andrew Cloke
Thanks to Dimitri for pointing out that the comment #2 is not designed
to actually SET the HW Clock from the host, but to ALLOW the HW Clock to
be set with /sbin/hwclock. I had completely missed this.

Next step is to try the sequence described in comment #2 (on the BMC and
also on the host), and then retry using /sbin/hwclock on the host to
change the HW clock time.

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1837443

Title:
  [Power9][Witherspoon dd2.3] unable to set hwclock

Status in The Ubuntu-power-systems project:
  In Progress
Status in util-linux package in Ubuntu:
  New

Bug description:
  On the upgraded witherspoon Power9 system we are unable to set
  hwclock.

  ubuntu@bobone:~$ uname -a 
  Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
  ubuntu@bobone:~$ cat /etc/issue
  Ubuntu 19.04 \n \l

  ubuntu@bobone:~$ date 
  Mon Jul 22 18:25:04 UTC 2019
  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock
  2019-07-22 18:25:26.799805+00:00
  ubuntu@bobone:~$ 

  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock --verbose
  hwclock from util-linux 2.33.1
  System Time: 1563820048.938797
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1101096600 seconds after 1969
  Last calibration done at 1101096600 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ioctl(4, RTC_UIE_ON, 0): Invalid argument
  Waiting in loop for time from /dev/rtc0 to change
  ...got clock tick
  Time read from Hardware Clock: 2019/07/22 18:27:29
  Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969
  Time since last adjustment is 462723449 seconds
  Calculated Hardware Clock drift is 0.00 seconds
  2019-07-22 18:27:28.877732+00:00
  ubuntu@bobone:~$

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1742941] Re: zlib: improve crc32 performance on P8

2019-08-27 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
 Assignee: Canonical Foundations Team (canonical-foundations) => 
(unassigned)

** Changed in: zlib (Ubuntu)
 Assignee: Canonical Foundations Team (canonical-foundations) => 
(unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1742941

Title:
  zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1841052] Re: [19.10 FEAT] gzip compression improvements - addl. patch required

2019-08-23 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1841052

Title:
  [19.10 FEAT] gzip compression improvements - addl. patch required

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released

Bug description:
  Due to fact that LP:
  https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350 is alread
  fix released , this new ticket is opened to fix a configuration
  problem:

  dpkg-buildpackage: info: source package gzip
  dpkg-buildpackage: info: source version 1.10-0ubuntu2
  ...
  configure: WARNING: unrecognized options: --enable-dfltc

  The configure flag: should be --enable-dfltcc

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1823157] Re: [19.10 FEAT] zlib compression improvements

2019-08-21 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1823157

Title:
  [19.10 FEAT] zlib compression improvements

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in zlib package in Ubuntu:
  Fix Released

Bug description:
  Compression improvements for Linux on z using zlib in support of
  better performance.

  Upstream post 2019-03-15: https://github.com/madler/zlib/pull/410

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1742941] Re: [18.10] zlib: improve crc32 performance on P8

2019-08-05 Thread Andrew Cloke
danie...@au1.ibm.com: has there been any outcome from the upstream talks
with Mark Adler?

** Summary changed:

- [18.10] zlib: improve  crc32 performance on P8
+ zlib: improve  crc32 performance on P8

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1742941

Title:
  zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1742941] Re: zlib: improve crc32 performance on P8

2019-08-05 Thread Andrew Cloke
Also, removing "18.10" from the title, as this release has EOLed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1742941

Title:
  zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock

2019-07-25 Thread Andrew Cloke
I believe /sbin/hwclock is the default tool for manually setting the
hwclock in Linux. I’m nervous that higher level workloads may depend on
the correct functioning of the /sbin/hwclock tool for their successful
operation.

The /sbin/hwclock tool is shipped with the util-linux package.

Adding util-linux as impacted and assigning to Foundations team to
comment on whether the /sbin/hwclock tool not operating on witherspoon
is a serious issue or not.


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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1837443

Title:
  [Power9][Witherspoon dd2.3] unable to set hwclock

Status in The Ubuntu-power-systems project:
  Triaged
Status in util-linux package in Ubuntu:
  New

Bug description:
  On the upgraded witherspoon Power9 system we are unable to set
  hwclock.

  ubuntu@bobone:~$ uname -a 
  Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
  ubuntu@bobone:~$ cat /etc/issue
  Ubuntu 19.04 \n \l

  ubuntu@bobone:~$ date 
  Mon Jul 22 18:25:04 UTC 2019
  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock
  2019-07-22 18:25:26.799805+00:00
  ubuntu@bobone:~$ 

  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock --verbose
  hwclock from util-linux 2.33.1
  System Time: 1563820048.938797
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1101096600 seconds after 1969
  Last calibration done at 1101096600 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ioctl(4, RTC_UIE_ON, 0): Invalid argument
  Waiting in loop for time from /dev/rtc0 to change
  ...got clock tick
  Time read from Hardware Clock: 2019/07/22 18:27:29
  Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969
  Time since last adjustment is 462723449 seconds
  Calculated Hardware Clock drift is 0.00 seconds
  2019-07-22 18:27:28.877732+00:00
  ubuntu@bobone:~$

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-06-27 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  Fix Released
Status in initramfs-tools source package in Disco:
  Fix Released

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  In order to verify the fix, one needs to change MODULES option to dep
  on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot,
  check the system has booted fine. That should not break on systems
  with non nvme disks or systems with non multipath nvme systems, and
  that should now work on multipath nvme systems.

  sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf
  update-initramfs -u -k all
  reboot

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.

  -

  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: 

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-06-24 Thread Andrew Cloke
Following call with IBM, verification testing is in progress. Hoping to
have test results posted in the next 24 hours (approx).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  Fix Committed
Status in initramfs-tools source package in Disco:
  Fix Released

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  In order to verify the fix, one needs to change MODULES option to dep
  on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot,
  check the system has booted fine. That should not break on systems
  with non nvme disks or systems with non multipath nvme systems, and
  that should now work on multipath nvme systems.

  sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf
  update-initramfs -u -k all
  reboot

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.

  -

  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  

[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel

2019-06-18 Thread Andrew Cloke
Next step is for this patch to go into the bionic gdb SRU queue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1830796

Title:
  [Bionic][ARM64]Failure debugging linux kernel

Status in gdb package in Ubuntu:
  Fix Released
Status in gdb source package in Bionic:
  In Progress

Bug description:
  [Impact]
  GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For 
example it is unable to print values of variables like 'jiffies_64'.

  [Test]
  # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic  /proc/kcore
  [New process 1]
  Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic 
root=UUID=edb5e5a7-8272-4e13-aa25-37'.
  #0  0x in ?? ()
  (gdb) p jiffies_64
  Cannot access memory at address 0x09616980
  (gdb)

  [Fix]
  This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by 
the following patch:
  8727de56b0  Fix tagged pointer support

  [Regression Potential]
  The risk of regression after applying this patch could be to architectures 
other than ARM64 due to changes to gdb/util.c. Please see comment #2 where I 
have tested the PPA package on a ppc64el system and found it does not introduce 
any regressions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-05-22 Thread Andrew Cloke
Thanks for the verification in comment #67. From the comment, I believe this 
was verified with bionic. Could you also verify with Cosmic and post your 
results?
Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Committed
Status in initramfs-tools source package in Cosmic:
  Fix Committed
Status in initramfs-tools source package in Disco:
  Fix Released

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  In order to verify the fix, one needs to change MODULES option to dep
  on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot,
  check the system has booted fine. That should not break on systems
  with non nvme disks or systems with non multipath nvme systems, and
  that should now work on multipath nvme systems.

  sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf
  update-initramfs -u -k all
  reboot

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.

  -

  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   

[Touch-packages] [Bug 1657646] Re: [20.04]Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

2019-05-09 Thread Andrew Cloke
Note that this is likely to require an MIR
(https://wiki.ubuntu.com/MainInclusionProcess) for thin-provisioning-
tools for 20.04.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1657646

Title:
  [20.04]Missing thin-provisioning-tools prevents VG with thin pool LV
  from being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Triaged
Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1657646] Re: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

2019-05-08 Thread Andrew Cloke
We will investigate and update this bug shortly.

I notice that this issue was raised some time ago. Is there any
additional information you can share as to recent specific use cases or
scenarios?

Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1657646

Title:
  Missing thin-provisioning-tools prevents VG with thin pool LV from
  being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Triaged
Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1657646] Re: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation

2019-05-03 Thread Andrew Cloke
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

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

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1657646

Title:
  Missing thin-provisioning-tools prevents VG with thin pool LV from
  being (de)activated, but not its creation

Status in The Ubuntu-power-systems project:
  Triaged
Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 package in Debian:
  New

Bug description:
  Creating a thin pool LV is allowed even when thin-provisioning-tools
  is not installed. But deactivating or activating that VG fails. Since
  deactivating the VG usually only happens at reboot, the user might
  fail to notice this big problem until then.

  I think the lvconvert tool, used to combine the two "thin LVs" into a
  thin pool LV, should refuse to run if thin-provisioning-tools, or the
  needed scripts, aren't installed.

  Steps to reproduce:
  root@15-89:~# vgcreate vg /dev/vdb1
    Volume group "vg" successfully created

  root@15-89:~# vgs
    VG   #PV #LV #SN Attr   VSize  VFree
    vg 1   0   0 wz--n- 40.00g 40.00g

  root@15-89:~# lvcreate -n pool0 -l 90%VG vg
    Logical volume "pool0" created.

  root@15-89:~# lvcreate -n pool0meta -l 5%VG vg
    Logical volume "pool0meta" created.

  root@15-89:~# lvs
    LVVG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%Sync Convert
    pool0 vg   -wi-a- 36.00g
    pool0meta vg   -wi-a-  2.00g

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 100 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3820 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:14 vg-pool0 -> ../dm-0
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0meta -> ../dm-1

  root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0
    WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data 
and metadata volumes.
    THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y
    Converted vg/pool0 to thin pool.

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root 120 Jun 21 14:15 ./
  drwxr-xr-x 20 root root3840 Jun 21 14:15 ../
  crw---  1 root root 10, 236 Jun 21 13:15 control
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0 -> ../dm-2
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1
  lrwxrwxrwx  1 root root   7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0
  root@15-89:~# lvs -a
    LV  VG   Attr   LSize  Pool Origin Data%  Meta%  Move Log 
Cpy%S
  ync Convert
    [lvol0_pmspare] vg   ewi---  2.00g
    pool0   vg   twi-a-tz-- 36.00g 0.00   0.01
    [pool0_tdata]   vg   Twi-ao 36.00g
    [pool0_tmeta]   vg   ewi-ao  2.00g

  If you now reboot the system, all that is gone:
  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:28 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:28 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

  The same happens if you deactivate the VG (which the reboot
  undoubtedly triggers). It fails because of a missing
  /usr/sbin/thin_check which is provided by the thin-provisioning-tools
  package:

  root@15-89:~# vgchange -a n
    /usr/sbin/thin_check: execvp failed: No such file or directory
    WARNING: Integrity check of metadata for pool vg/pool0 failed.
    0 logical volume(s) in volume group "vg" now active

  root@15-89:~# ll /dev/mapper/
  total 0
  drwxr-xr-x  2 root root  60 Jun 21 14:29 ./
  drwxr-xr-x 19 root root3760 Jun 21 14:29 ../
  crw---  1 root root 10, 236 Jun 21 14:28 control

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1742941] Re: [18.10] zlib: improve crc32 performance on P8

2019-04-29 Thread Andrew Cloke
** Changed in: zlib (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1742941

Title:
  [18.10] zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-04-29 Thread Andrew Cloke
Added to the SRU queue on 22nd April. Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in initramfs-tools source package in Disco:
  Fix Released

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  In order to verify the fix, one needs to change MODULES option to dep
  on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot,
  check the system has booted fine. That should not break on systems
  with non nvme disks or systems with non multipath nvme systems, and
  that should now work on multipath nvme systems.

  sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf
  update-initramfs -u -k all
  reboot

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.

  -

  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   

[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-04-01 Thread Andrew Cloke
Great. Thanks Dimitri. We'd missed that upload.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1818953

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Confirmed
Status in perl package in Ubuntu:
  Confirmed
Status in perl source package in Disco:
  Confirmed
Status in perl package in Debian:
  Unknown

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-04-01 Thread Andrew Cloke
Hi Thadeu, thanks for the update.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in linux source package in Cosmic:
  Invalid
Status in initramfs-tools source package in Disco:
  In Progress
Status in linux source package in Disco:
  Invalid

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.


  -

  
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 

[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest

2019-04-01 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Triaged => Incomplete

** Changed in: util-linux (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1764628

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

Status in The Ubuntu-power-systems project:
  Incomplete
Status in util-linux package in Ubuntu:
  Incomplete

Bug description:
  ---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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-04-01 Thread Andrew Cloke
Next step: Thadeu to propose the diff described in comment #53 into the archive.
(If this incorrect, please flag.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in linux source package in Cosmic:
  Invalid
Status in initramfs-tools source package in Disco:
  In Progress
Status in linux source package in Disco:
  Invalid

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.


  -

  
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-03-26 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Won't Fix => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in makedumpfile package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Invalid
Status in makedumpfile source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  In Progress
Status in linux source package in Cosmic:
  Invalid
Status in makedumpfile source package in Cosmic:
  Invalid
Status in initramfs-tools source package in Disco:
  In Progress
Status in linux source package in Disco:
  Invalid
Status in makedumpfile source package in Disco:
  Invalid

Bug description:
  [Impact]
  initramfs created with MODULES=dep or kdump initrd won't boot a system with 
root filesystem on a multipath nvme.

  [Test case]
  Systems with nvme multipath were able to boot with the created initramfs. 
Also tested on systems with non-multipath nvme, and non nvme systems.

  [Regression potential]
  A system could fail to boot because the generated initramfs was broken. The 
code should just add modules, which is safer than removing modules or doing any 
other changes. In any case, it was tested to boot on multipath nvme, non 
multipath nvme and non nvme systems.


  -

  
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 

[Touch-packages] [Bug 1733870] Re: [Ubuntu 19.10] Add GDB support to access/display POWER8 registers

2019-03-26 Thread Andrew Cloke
Based comments #6, #7 and #8, closing this bug out.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1733870

Title:
  [Ubuntu 19.10] Add GDB support to access/display POWER8 registers

Status in The Ubuntu-power-systems project:
  Fix Released
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  This feature request is for GDB support for access to Power registers
  that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM
  registers.

  The feature is currently being worked on, so no upstream code is
  available yet.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1818953] Re: Perl core dumping core on UBUNTU 19.04 by executing perl script

2019-03-11 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1818953

Title:
  Perl core dumping core on UBUNTU 19.04 by executing perl script

Status in The Ubuntu-power-systems project:
  Incomplete
Status in perl package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-02-11 Thread Andrew Cloke
Thanks. Closing out the bug.

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

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: Confirmed => Invalid

** Changed in: initramfs-tools (Ubuntu Cosmic)
   Status: Confirmed => Invalid

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

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Won't Fix
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in makedumpfile package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  Invalid
Status in makedumpfile source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  Invalid
Status in linux source package in Cosmic:
  Invalid
Status in makedumpfile source package in Cosmic:
  Invalid

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: 

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-02-11 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in makedumpfile source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Confirmed
Status in makedumpfile source package in Cosmic:
  Invalid

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-02-05 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in makedumpfile source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Confirmed
Status in makedumpfile source package in Cosmic:
  Invalid

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 

[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath

2019-01-18 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784347

Title:
  ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting
  partitions name for the mpath

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

Bug description:
  
  [Impact]
  Any user of Ubuntu on multipath, where the default path separator has been 
changed to something else. This possibly affects other scenarios where the 
partition separator can be changed.

  [Test case]
  1) Install Ubuntu on multipath system
  2) Change /etc/multipath.conf to set "path_separator" to "" or "p".
  3) Reboot
  4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions 
where the path separator would be visible.

  
  [Regression potential]
  Minimal. This only affects display. Default separator on Ubuntu remains 
"-part". If the separator is not one of "", "p", or "-part", then "-part" would 
be used, as is already the case.

  
  == Comment: #0 - Chanh H. Nguyen  - 2018-01-09 11:14:07 
==
  We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the 
Emulex adapter to have the mpath disk.
  Running the fdisk -l and ls -l showing the conflict name for the mpath.

  :~# uname -a
  Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@boslcp4:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="18.04 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Bionic Beaver (development branch)"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part1   2048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2  419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3  838862848 1258291199 419428352  200G 83 Linux

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:04 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha3 -> ../dm-3

  == Comment: #2 - Chanh H. Nguyen  - 2018-01-09 11:35:04 
==
  I just modify the partitions and it is still showing the conflicting name on 
partitions.

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha3 -> ../dm-3
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha4 -> ../dm-4
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha5 -> ../dm-5
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha6 -> ../dm-6
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha7 -> ../dm-7
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha8 -> ../dm-8

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot  StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part12048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2   419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3   838862848  964691967 125829120   60G 83 Linux
  /dev/mapper/mpatha-part4   964691968 1258291199 293599232  140G  5 
Extended
  /dev/mapper/mpatha-part5   964694016 1006637055  41943040   20G 83 Linux
  /dev/mapper/mpatha-part6  1006639104 1048582143  41943040   20G 83 Linux
  /dev/mapper/mpatha-part7  1048584192 1090527231  41943040   20G 83 Linux
  /dev/mapper/mpatha-part8  1090529280 1132472319  41943040   20G 83 Linux

  == Comment: #5 - Kyle Mahlkuch  - 2018-06-26 13:50:12 
==
  I have created and submitted a 

[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships

2019-01-17 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  nvme multipath does not report path relationships

Status in The Ubuntu-power-systems project:
  Incomplete
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in makedumpfile source package in Bionic:
  Invalid
Status in initramfs-tools source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Confirmed
Status in makedumpfile source package in Cosmic:
  Invalid

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 

[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath

2018-12-06 Thread Andrew Cloke
Update: IBM is working on the bionic verification.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784347

Title:
  ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting
  partitions name for the mpath

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 Bionic:
  Incomplete

Bug description:
  
  [Impact]
  Any user of Ubuntu on multipath, where the default path separator has been 
changed to something else. This possibly affects other scenarios where the 
partition separator can be changed.

  [Test case]
  1) Install Ubuntu on multipath system
  2) Change /etc/multipath.conf to set "path_separator" to "" or "p".
  3) Reboot
  4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions 
where the path separator would be visible.

  
  [Regression potential]
  Minimal. This only affects display. Default separator on Ubuntu remains 
"-part". If the separator is not one of "", "p", or "-part", then "-part" would 
be used, as is already the case.

  
  == Comment: #0 - Chanh H. Nguyen  - 2018-01-09 11:14:07 
==
  We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the 
Emulex adapter to have the mpath disk.
  Running the fdisk -l and ls -l showing the conflict name for the mpath.

  :~# uname -a
  Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@boslcp4:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="18.04 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Bionic Beaver (development branch)"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part1   2048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2  419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3  838862848 1258291199 419428352  200G 83 Linux

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:04 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha3 -> ../dm-3

  == Comment: #2 - Chanh H. Nguyen  - 2018-01-09 11:35:04 
==
  I just modify the partitions and it is still showing the conflicting name on 
partitions.

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha3 -> ../dm-3
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha4 -> ../dm-4
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha5 -> ../dm-5
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha6 -> ../dm-6
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha7 -> ../dm-7
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha8 -> ../dm-8

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot  StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part12048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2   419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3   838862848  964691967 125829120   60G 83 Linux
  /dev/mapper/mpatha-part4   964691968 1258291199 293599232  140G  5 
Extended
  /dev/mapper/mpatha-part5   964694016 1006637055  41943040   20G 83 Linux
  /dev/mapper/mpatha-part6  1006639104 1048582143  41943040   20G 83 Linux
  /dev/mapper/mpatha-part7  1048584192 1090527231  41943040   20G 83 Linux
  /dev/mapper/mpatha-part8  1090529280 1132472319  41943040   20G 83 Linux

  == Comment: #5 - Kyle Mahlkuch  - 2018-06-26 13:50:12 
==
  I have created and submitted a patch that should help with 

[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath

2018-12-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Foundations Team 
(canonical-foundations)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784347

Title:
  ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting
  partitions name for the mpath

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 Bionic:
  Incomplete

Bug description:
  
  [Impact]
  Any user of Ubuntu on multipath, where the default path separator has been 
changed to something else. This possibly affects other scenarios where the 
partition separator can be changed.

  [Test case]
  1) Install Ubuntu on multipath system
  2) Change /etc/multipath.conf to set "path_separator" to "" or "p".
  3) Reboot
  4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions 
where the path separator would be visible.

  
  [Regression potential]
  Minimal. This only affects display. Default separator on Ubuntu remains 
"-part". If the separator is not one of "", "p", or "-part", then "-part" would 
be used, as is already the case.

  
  == Comment: #0 - Chanh H. Nguyen  - 2018-01-09 11:14:07 
==
  We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the 
Emulex adapter to have the mpath disk.
  Running the fdisk -l and ls -l showing the conflict name for the mpath.

  :~# uname -a
  Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@boslcp4:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="18.04 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Bionic Beaver (development branch)"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part1   2048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2  419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3  838862848 1258291199 419428352  200G 83 Linux

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:04 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha3 -> ../dm-3

  == Comment: #2 - Chanh H. Nguyen  - 2018-01-09 11:35:04 
==
  I just modify the partitions and it is still showing the conflicting name on 
partitions.

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha3 -> ../dm-3
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha4 -> ../dm-4
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha5 -> ../dm-5
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha6 -> ../dm-6
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha7 -> ../dm-7
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha8 -> ../dm-8

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot  StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part12048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2   419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3   838862848  964691967 125829120   60G 83 Linux
  /dev/mapper/mpatha-part4   964691968 1258291199 293599232  140G  5 
Extended
  /dev/mapper/mpatha-part5   964694016 1006637055  41943040   20G 83 Linux
  /dev/mapper/mpatha-part6  1006639104 1048582143  41943040   20G 83 Linux
  /dev/mapper/mpatha-part7  1048584192 1090527231  41943040   20G 83 Linux
  /dev/mapper/mpatha-part8  1090529280 1132472319  41943040   20G 83 Linux

  == Comment: #5 - Kyle Mahlkuch  - 2018-06-26 13:50:12 

[Touch-packages] [Bug 1776626] Re: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part

2018-11-19 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1776626

Title:
  [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab
  part

Status in Ubuntu on IBM z Systems:
  In Progress
Status in cryptsetup package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cryptsetup source package in Bionic:
  New
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * cryptsetup in bionic supports creating luks volumes with a non-
  standard sector-size option, and thus this option also needs to be
  used when activating the LUKS volumes. Add sector-size= option support
  to /etc/crypttab.

  [Test Case]

   * Create a plain LUKS volume with sector-size 4096
   * Specify sector-size=4096 option in /etc/crypttab
   * reload systemd, start systemd-cryptsetup@.service for that volume
   * check the journal, to ensure that `sector-size` option was recognized and 
is active. (i.e. there is not error messages about unrecognized option 
`sector-size` from systemd-cryptsetup)

  [Regression Potential]

   * This is an optional argument, not used by default. Currently custom
  sector-size crypttab does not work correctly, and thus cannot regress.

  [Other Info]
   
   * Original bug report

  Support fast clear key dm-crypt with 4k support

  Extend /etc/crypttab  to enable 4k sector support in plain mode

  The proposed enhancements are posted on github, see
   https://github.com/systemd/systemd/issues/8881

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath

2018-10-17 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784347

Title:
  ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting
  partitions name for the mpath

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 Bionic:
  Fix Committed

Bug description:
  
  [Impact]
  Any user of Ubuntu on multipath, where the default path separator has been 
changed to something else. This possibly affects other scenarios where the 
partition separator can be changed.

  [Test case]
  1) Install Ubuntu on multipath system
  2) Change /etc/multipath.conf to set "path_separator" to "" or "p".
  3) Reboot
  4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions 
where the path separator would be visible.

  
  [Regression potential]
  Minimal. This only affects display. Default separator on Ubuntu remains 
"-part". If the separator is not one of "", "p", or "-part", then "-part" would 
be used, as is already the case.

  
  == Comment: #0 - Chanh H. Nguyen  - 2018-01-09 11:14:07 
==
  We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the 
Emulex adapter to have the mpath disk.
  Running the fdisk -l and ls -l showing the conflict name for the mpath.

  :~# uname -a
  Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@boslcp4:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="18.04 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Bionic Beaver (development branch)"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part1   2048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2  419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3  838862848 1258291199 419428352  200G 83 Linux

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:04 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha3 -> ../dm-3

  == Comment: #2 - Chanh H. Nguyen  - 2018-01-09 11:35:04 
==
  I just modify the partitions and it is still showing the conflicting name on 
partitions.

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha3 -> ../dm-3
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha4 -> ../dm-4
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha5 -> ../dm-5
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha6 -> ../dm-6
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha7 -> ../dm-7
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha8 -> ../dm-8

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot  StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part12048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2   419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3   838862848  964691967 125829120   60G 83 Linux
  /dev/mapper/mpatha-part4   964691968 1258291199 293599232  140G  5 
Extended
  /dev/mapper/mpatha-part5   964694016 1006637055  41943040   20G 83 Linux
  /dev/mapper/mpatha-part6  1006639104 1048582143  41943040   20G 83 Linux
  /dev/mapper/mpatha-part7  1048584192 1090527231  41943040   20G 83 Linux
  /dev/mapper/mpatha-part8  1090529280 1132472319  41943040   20G 83 Linux

  == Comment: #5 - Kyle Mahlkuch  - 2018-06-26 13:50:12 
==
  I have created and submitted a 

[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state

2018-09-24 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Incomplete => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering
  crash,kdump is not working and system enters into initramfs state

Status in The Ubuntu-power-systems project:
  Triaged
Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in linux source package in Bionic:
  New
Status in makedumpfile source package in Bionic:
  New

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 0001  
7efce644
  [   73.058099] GPR24: 7efce640 0e4f79d8afb4 c15e9aa8 

[Touch-packages] [Bug 1793369] Re: Ubuntu18.10:ppc64:s390x - Sysrq trigger disabled when writing to /proc/sysrq-trigger

2018-09-21 Thread Andrew Cloke
** Changed in: systemd (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1793369

Title:
  Ubuntu18.10:ppc64:s390x - Sysrq trigger disabled when writing to /proc
  /sysrq-trigger

Status in The Ubuntu-power-systems project:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Cosmic:
  Invalid
Status in systemd source package in Cosmic:
  Won't Fix

Bug description:
  == Comment: #0 - Praveen K. Pandey  - 2018-09-19 
04:49:39 ==
  ---Problem Description---
   [Witherspoon-DD2.2][Ubu 18.10] [4.18.0-7-generic ] : Sysrq trigger disabled 
when writing to /proc/sysrq-trigger 

  while  testing kdump trying trigger kdump panic via /proc/sysrq-trigger it 
failed as : SysRq : This sysrq operation is disabled
  LOG:

  root@test:~# cat /proc/sys/kernel/sysrq 
  176
  root@test:~# echo c > /proc/sysrq-trigger
  root@test:~# dmesg
  [  380.340051] mlx5_core :01:00.1 enp1s0f1: Self test out: status 
flags(0x2)
  [  389.404239] sysrq: SysRq : This sysrq operation is disabled.
  root@test~# cat /boot/config-4.18.0-7-generic | grep CONFIG_MAGIC_SYSRQ
  CONFIG_MAGIC_SYSRQ=y
  CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6
  CONFIG_MAGIC_SYSRQ_SERIAL=y
  root@test:~# cat /etc/sysctl.conf | grep kernel.sysrq
  #kernel.sysrq=438
  root@test:~# 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.18.0-7-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.18.0-7-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=c0302064-c5a3-49a7-8bd4-402283e6fcbe ro quiet splash 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
  root@test:~# 

  Regards
  Praveen

  == Comment: #2 - Praveen K. Pandey  - 2018-09-19 
05:16:11 ==
  when i enable  in /etc/sysctl.conf it works  . i append below value in  
sysctl.conf

  echo "kernel.sysrq = 1" >> /etc/sysctl.conf

  I think this is should be enable by default  in ubuntu 18.10 as
  earlier ubuntu distro it has , not sure why it got removed as kdump
  mechanism require this .

  Praveen
  Regards

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1781242] Re: as segfault with invalid -march= option

2018-09-20 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1781242

Title:
  as segfault with invalid -march= option

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * as segfaults, instead of exiting gracefully, when one specifies 
unsupported arch option (ie. one from future - cause xenial did not support z14)
   * this is bad, as detection fails around supported march options - as if 
binutils are completely broken, rather than just not supporting this or that 
CPU level of optimisations.

  [Test Case]

  Bad result:
   $ as -march=foo
  Segmentation fault

  Expected result:
  # as -march=foo
  Assembler messages:
  Error: invalid switch -march=foo
  Error: unrecognized option -march=foo

  [Regression Potential]

   * The result is still a failure condition, but with a proper exit
  code and standard error messages, rather than an unexplainable generic
  segfault.

  [Other Info]
   
   * Original bug report

  The GNU assembler segfaults with an invalid -march= option

  Contact Information = n/a

  ---uname output---
  n/a

  Machine Type = n/a

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

  ---Steps to Reproduce---
   $ as -march=foo
  Segmentation fault

  Expected result:
  # as -march=foo
  Assembler messages:
  Error: invalid switch -march=foo
  Error: unrecognized option -march=foo

  Userspace tool common name: as

  The userspace tool has the following bit modes: 64

  Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6

  Userspace tool obtained from project website:  na

  *Additional Instructions for n/a:
  -Attach ltrace and strace of userspace application.

  The problem is not critical since usually 'as' is invoked through the
  gcc driver which itself errors out for wrong -march= options. It will
  only be a problem if somebody builds a more recent GCC from source and
  uses an -march= option for a machine not supported by the default
  binutils.

  Please consider integrating the attached patch into 16.04 binutils.

  The problem has been fixed in later binutils already. Ubuntu 18.04
  does not appear to be affected.

  --> Package has to set corectly by Canonical

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1786940] Re: Enable arm-linux-gnueabi target on ppc64el toolchain

2018-09-17 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1786940

Title:
  Enable arm-linux-gnueabi target on ppc64el toolchain

Status in The Ubuntu-power-systems project:
  Incomplete
Status in binutils package in Ubuntu:
  Fix Released
Status in gcc-7-cross package in Ubuntu:
  New
Status in gcc-8-cross package in Ubuntu:
  New
Status in gcc-defaults package in Ubuntu:
  Incomplete

Bug description:
  Dear Canonical.

  We would like to have arm-linux-gnueabi target on ppc64el cross
  toolchain. This would enable us to use a ppc64el host to do cross
  compilation for aarch64.

  I talked to Matthias Klose already, and he is aware of this request.

  Thank you,
  Breno

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1776626] Re: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part

2018-09-05 Thread Andrew Cloke
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1776626

Title:
  [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab
  part

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in cryptsetup package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  Support fast clear key dm-crypt with 4k support

  Extend /etc/crypttab  to enable 4k sector support in plain mode

  The proposed enhancements are posted on github, see 
   https://github.com/systemd/systemd/issues/8881

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1733870] Re: [Ubuntu 19.04] Add GDB support to access/display POWER8 registers

2018-08-21 Thread Andrew Cloke
** Summary changed:

- [Ubuntu 18.10] Add GDB support to access/display POWER8 registers
+ [Ubuntu 19.04] Add GDB support to access/display POWER8 registers

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1733870

Title:
  [Ubuntu 19.04] Add GDB support to access/display POWER8 registers

Status in The Ubuntu-power-systems project:
  Incomplete
Status in gdb package in Ubuntu:
  Incomplete

Bug description:
  This feature request is for GDB support for access to Power registers
  that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM
  registers.

  The feature is currently being worked on, so no upstream code is
  available yet.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

2018-07-26 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732865

Title:
  [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min
  frequencies

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

Bug description:
  [Impact]
  lscpu fails to list CPU max and min frequencies if some CPUs are guarded.

  [Regression potential]
  Isolated change to lscpu min/max CPU frequency output, so the worst that 
could happen is that it fails to work elsewhere.

  [Test case]
  1. Clone https://github.com/open-power/op-test-framework
  2. Run this command to GUARD the cpu.
  ./op-test --bmc-type FSP --bmc-ip $FSPIP --bmc-username dev --bmc-password 
FipSdev --host-ip $HOSTIP --host-user root --host-password passw0rd --ffdcdir 
test-reports/ --run testcases.OpTestHMIHandling.MalfunctionAlert
  3. Repeat again, so that multiple CPUs are guarded.
  4. Run lscpu
  5. Observe that no CPU frequencies are displayed:
  CPU max MHz: (null)
  CPU min MHz: (null)
  6. Install util-linux from -proposed.
  7. Run lscpu again
  8. Observe that max and min CPU frequencies are correctly displayed.

  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-01-03 
05:34:32 ==
  ---Problem Description---
  After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies

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

  ---uname output---
  Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 
UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = PowerNV 8284-22A

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

  ---Steps to Reproduce---
   1. Read lscpu output
  2. Inject HMI Non recoverable error three times
  3. Read lscpu output again
  compare the output cpu frequencies will list as NULL

  Stack trace output:
   no

  Oops output:
   no

  Userspace tool common name: lscpu

  Userspace rpm: util-linux

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

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

  Userspace tool obtained from project website:  na

  *Additional Instructions for ppaid...@in.ibm.com:
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of userspace application.

  Before CPU's are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):112
  On-line CPU(s) list:   0-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   4322.
  CPU min MHz:   2061.
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 0-31
  NUMA node1 CPU(s): 32-63
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  After 4 cores are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):96
  On-line CPU(s) list:   8-55,64-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   (null)
  CPU min MHz:   (null)
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 8-31
  NUMA node1 CPU(s): 32-55
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  == Comment: #1 - Pridhiviraj Paidipeddi  - 2017-01-11 
07:06:59 ==
  root@p8wookie:~# dmesg |grep -i powernv
  [0.00] Using PowerNV machine description
  [0.331564] EEH: PowerNV platform initialized
  [0.907250] powernv-rng: Registering arch random hook.
  [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
  [1.507167] powernv_idle_driver registered
  [   34.184048] powernv_rng: Registered powernv hwrng.
  [   34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
  [   34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, 
prod_id: 0x, dev_id: 0x00)
  root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
  [   42.297825315,7]   OCC Common Area at 0x3b0 size 1MB
  [   42.297854780,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297884305,7]   OCC 

[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state

2018-07-23 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Incomplete => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering
  crash,kdump is not working and system enters into initramfs state

Status in The Ubuntu-power-systems project:
  Triaged
Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in linux source package in Bionic:
  New
Status in makedumpfile source package in Bionic:
  New

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 0001  
7efce644
  [   73.058099] GPR24: 7efce640 0e4f79d8afb4 c15e9aa8 

[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state

2018-07-20 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1778844

Title:
  ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering
  crash,kdump is not working and system enters into initramfs state

Status in The Ubuntu-power-systems project:
  Incomplete
Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in linux source package in Bionic:
  New
Status in makedumpfile source package in Bionic:
  New

Bug description:
  Problem Description:
  ===
  After triggering crash ,kdump is not working & system enters into initramfs 
state

  Steps to re-create:
  ==

  >. woo is installed ubuntu180401 kernel

  root@woo:~# uname -a
  Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
  root@woo:~#

  >. Crashkernel value as below

  root@woo:~# free -h
totalusedfree  shared  buff/cache   
available
  Mem:   503G2.0G501G 13M279M
499G
  Swap:  2.0G  0B2.0G

  root@woo:~# cat /proc/cmdline
  root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
crashkernel=8192M

  >  kdump status

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

  root@woo:~#  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.15.0-23-generic
  kdump initrd:
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.15.0-23-generic
  current state:ready to kdump

  kexec command:
/sbin/kexec -p 
--command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet 
nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" 
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

  root@woo:~# dmesg | grep Reser
  [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System 
RAM: 524288MB)
  [0.00] cma: Reserved 26224 MiB at 0x20399500
  [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The 
term "Broadcom" refers to Broadcom Limited and/or its subsidiaries.

  > Triggered crash

  root@woo:~# echo 1 > /proc/sys/kernel/sysrq
  root@woo:~# echo c > /proc/sysrq-trigger
  [   73.056308] sysrq: SysRq : Trigger a crash
  [   73.056357] Unable to handle kernel paging request for data at address 
0x
  [   73.056459] Faulting instruction address: 0xc07f24c8
  [   73.056543] Oops: Kernel access of bad area, sig: 11 [#1]
  [   73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV
  [   73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) 
iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 
esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) 
mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx 
vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 
powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd 
auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables 
autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc 
ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink 
syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops 
nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc
  [   73.057601]  tg3 libahci nvme_core pnv_php
  [   73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G   OE
4.15.0-23-generic #25-Ubuntu
  [   73.057767] NIP:  c07f24c8 LR: c07f3568 CTR: 
c07f24a0
  [   73.057868] REGS: c03f8269f9f0 TRAP: 0300   Tainted: G   OE
 (4.15.0-23-generic)
  [   73.057986] MSR:  90009033   CR: 2822 
 XER: 2004
  [   73.058099] CFAR: c07f3564 DAR:  DSISR: 4200 
SOFTE: 1
  [   73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 
0063
  [   73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 
31da0058
  [   73.058099] GPR08: 0007 0001  
90001003
  [   73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 

  [   73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 
0e4f79d56818
  [   73.058099] GPR20: 0e4f79d8d5d8 0001  
7efce644
  [   73.058099] GPR24: 7efce640 0e4f79d8afb4 c15e9aa8 

[Touch-packages] [Bug 1751813] Re: Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array [S822L] [ipr]

2018-04-24 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751813

Title:
  Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array
  [S822L] [ipr]

Status in The Ubuntu-power-systems project:
  Fix Released
Status in debian-installer package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  ---Problem Description---
  Ubuntu 18.04 ppc64el installer does detect IPR (IBM Power RAID) based 
HDD/RAID arrays

  Tried with current bionic and current bionic-proposed installers
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz
  kexec -l vmlinux -i initrd.gz
  kexec -e

  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/bionic-proposed/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux
  wget 
http://ports.ubuntu.com/ubuntu-ports/dists/bionic-proposed/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz
   kexec -l vmlinux -i initrd.gz
  kexec -e

  ---uname output---
  uname -a
  Linux ltciofvtr-s822l2-lp1 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 
09:05:20 UTC 2018 ppc64le GNU/Linux

  Machine Type = 8247-22L (S822L)
   
  ---boot type---
  Network boot
   
  ---bootloader---
  petitboot shell
   
  ---Kernel cmdline used to launch install---
  #cat /proc/cmdline

  ---Bootloader protocol---
  http
   
  ---Install repository type---
  Internet repository
   
  ---Install repository Location---
  US
   
  ---Point of failure---
  Problem during post-install (stage 2) configuration or other problem seen 
after reboot

  ===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:   ?
? ?
? SCSI1 (0,0,0) (sda) - 2.0 GB SMART USB-IBM  ?
? SCSI2 (0,0,0) (sdb) - 1.0 TB IBM T RDX-USB3 ?
? ?
??
? ?
???



   moves;  selects;  activates buttons

  
  ~ # lsmod | grep -i ipr
  ipr   148677  0
  ~ # modinfo ipr
  filename:   /lib/modules/4.13.0-32-generic/kernel/drivers/scsi/ipr.ko
  version:2.6.4
  license:GPL
  description:IBM Power RAID SCSI Adapter Driver
  author: Brian King 
  srcversion: 05BB872A11F65B3A73AB352
  alias:  pci:v1014d04DAsv1014sd04FBbc*sc*i*
  alias:  pci:v1014d04DAsv1014sd04FCbc*sc*i*
  alias:  pci:v1014d034Asv1014sd04C9bc*sc*i*
  alias:  pci:v1014d034Asv1014sd04C8bc*sc*i*
  alias:  pci:v1014d034Asv1014sd04C7bc*sc*i*
  alias:  pci:v1014d034Asv1014sd049Cbc*sc*i*
  alias:  pci:v1014d034Asv1014sd049Bbc*sc*i*
  alias:  pci:v1014d034Asv1014sd049Abc*sc*i*
  alias:  pci:v1014d034Asv1014sd0499bc*sc*i*
  alias:  pci:v1014d034Asv1014sd0475bc*sc*i*
  alias:  pci:v1014d034Asv1014sd0474bc*sc*i*
  alias:  pci:v1014d034Asv1014sd04CAbc*sc*i*
  alias:  pci:v1014d034Asv1014sd046Dbc*sc*i*
  alias:  pci:v1014d034Asv1014sd03FEbc*sc*i*
  alias:  pci:v1014d034Asv1014sd03FFbc*sc*i*
  alias:  pci:v1014d034Asv1014sd03FCbc*sc*i*
  alias:  pci:v1014d034Asv1014sd03FBbc*sc*i*
  alias:  pci:v1014d034Asv1014sd035Ebc*sc*i*
  alias:  pci:v1014d034Asv1014sd035Dbc*sc*i*
  alias:  pci:v1014d034Asv1014sd0357bc*sc*i*
  alias:  pci:v1014d034Asv1014sd0355bc*sc*i*
  alias:  pci:v1014d034Asv1014sd033Bbc*sc*i*
  

[Touch-packages] [Bug 1719579] Re: [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save

2018-04-18 Thread Andrew Cloke
>From comment #22: "Distro team, Is there any update based on the
previous update we posted. ?"

I'm afraid this bug report is now a little complex and involved, and it
is now marked as "Fix Released" in Launchpad.

Could you please be specific about the comment or question that you
require more information about? Alternatively, it may be best to raise a
new bug report.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1719579

Title:
  [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in
  /var/tmp folder using virsh save

Status in The Ubuntu-power-systems project:
  Fix Released
Status in apparmor package in Ubuntu:
  Invalid
Status in libvirt package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #1 - SEETEENA THOUFEEK  - 2017-01-17 
00:09:16 ==
  Bala, Please mail me the machine information.

  == Comment: #3 - SEETEENA THOUFEEK  - 2017-01-17 
02:14:06 ==
  2017-01-16 12:09:37.707+: 7024: info : 
virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on 
'/var/tmp/bala'
  2017-01-16 12:09:37.707+: 7024: info : 
virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on 
'/var/tmp/bala' to '0:0'
  2017-01-16 12:09:37.707+: 7024: warning : qemuDomainSaveImageStartVM:6750 
: failed to restore save state label on /var/tmp/bala
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: debug : qemuDomainObjEndAsyncJob:1848 : 
Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala)
  2017-01-16 12:09:37.707+: 7024: info : virObjectRef:296 : OBJECT_REF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca535c0
  2017-01-16 12:09:37.707+: 7024: debug : virThreadJobClear:121 : Thread 
7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with 
ret=-1
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff7c002c10
  2017-01-16 12:09:37.707+: 7024: debug : virNetServerProgramSendError:153 
: prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590 
rerr=0x3fffa59be3c0
  2017-01-16 12:09:37.707+: 7024: debug : virNetMessageEncodePayload:376 : 
Encode length as 172
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172 
offset=0
  2017-01-16 12:09:37.707+: 7024: info : 
virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: 
client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1 
serial=4
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670 
tx=0x100133d2590
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientCalculateHandleMode:192 : mode=3
  2017-01-16 12:09:37.707+: 7024: info : virEventPollUpdateHandle:152 : 
EVENT_POLL_UPDATE_HANDLE: watch=417 events=3
  2017-01-16 12:09:37.707+: 7024: debug : virEventPollInterruptLocked:727 : 
Interrupting
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff7c002c10
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x100133caea0
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x100133d23c0
  .
  2017-01-16 12:14:28.445+: 7019: info : qemuMonitorJSONIOProcessLine:201 : 
QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds": 
1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status": 
"failed"}}
  2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorJSONIOProcessEvent:147 
: mon=0x3fff94004d90 obj=0x100133b5670
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1762 : 
object=0x100133a8000
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : 
object=0x100133a8000 type=0 gen=0x100133d1160
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : 
object=0x100133d2a80 type=2 gen=0x100133d1160
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1795 : 
result={"status":"failed"}
  2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorEmitEvent:1218 : 
mon=0x3fff94004d90 event=MIGRATION
  2017-01-16 12:14:28.445+: 7019: info : virObjectRef:296 : OBJECT_REF: 
obj=0x3fff94004d90
  2017-01-16 12:14:28.445+: 7019: debug : qemuProcessHandleEvent:629 : 
vm=0x3fff4ca535c0
  2017-01-16 12:14:28.445+: 7019: info : virObjectNew:202 : OBJECT_NEW: 
obj=0x100133d2870 classname=virDomainQemuMonitorEvent
  2017-01-16 12:14:28.445+: 7019: debug : virObjectEventNew:645 : 
obj=0x100133d2870
  

[Touch-packages] [Bug 1679704] Re: libvirt profile is blocking global setrlimit despite having no rlimit rule

2018-04-05 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Security Team (canonical-security)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1679704

Title:
  libvirt profile is blocking global setrlimit despite having no rlimit
  rule

Status in The Ubuntu-power-systems project:
  In Progress
Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  Hi,
  while debugging bug 1678322 I was running along apparmor issues.
  Thanks to jjohansen we debugged some of it and eventually I was asked to 
report to a bug.

  Symptom:
  [ 8976.950635] audit: type=1400 audit(1491310016.224:48): apparmor="DENIED" 
operation="setrlimit" profile="/usr/sbin/libvirtd" pid=10034 comm="libvirtd" 
rlimit=memlock value=1610612736

  But none of the profiles has any rlimit statement in it:
  $ grep -Hirn limit /etc/apparmor*
  /etc/apparmor.d/sbin.dhclient:58:  # such, if the dhclient3 daemon is 
subverted, this effectively limits it to
  /etc/apparmor.d/abstractions/ubuntu-helpers:16:# Limitations:
  /etc/apparmor.d/abstractions/ubuntu-helpers:64:  # in limited libraries so 
glibc's secure execution should be enough to not
  /etc/apparmor.d/cache/.features:13:rlimit {mask {cpu fsize data stack core 
rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime

  
  The profile contains a child profile which makes reading the dumps a bit 
painful, but I'll attach them anyway for you to take a look.
  To "recreate" if needed check out bug 1678322 - TL;DR hot-add some VFs via 
libvirt.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1708409] Re: kdump service does not start after configure/reboot

2018-03-21 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1708409

Title:
  kdump service does not start after configure/reboot

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

Bug description:
  == Comment: #0 - Harish Sriram  - 2017-08-02 01:45:01 ==
  kdump service does not start after configure/reboot

  --Problem Description---
  kdump service does not start after configure/reboot. It has to be 
started/loaded manually, everytime after reboot.

  # kdump-config status
  current state   : Not ready to kdump

  
  ---uname output---
  Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux 
   
  Machine Type/Model = Power 8/8247-22L 

  Additional Info-
  # cat /proc/cmdline
  root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 
console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
   
  ---Steps to Reproduce---
  1. installed linux-crashdump
  2. edited the kdump-tools.cfg crashkernel cmdline to above
  3. update-grub
  4. reboot

  Expected:
  kdump-config to be loaded by default after reboot

  # kdump-config status
  current state   : Not ready to kdump

  # service kdump-tools status
  * kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: inactive (dead)

  ...
  https://github.com/systemd/systemd/issues/6334

  systemd in artful is not properly picking up the unit files in 
  /etc/systemd/system/default.target.wants

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1708409] Re: kdump service does not start after configure/reboot

2018-03-08 Thread Andrew Cloke
** Changed in: makedumpfile (Ubuntu Artful)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1708409

Title:
  kdump service does not start after configure/reboot

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

Bug description:
  == Comment: #0 - Harish Sriram  - 2017-08-02 01:45:01 ==
  kdump service does not start after configure/reboot

  --Problem Description---
  kdump service does not start after configure/reboot. It has to be 
started/loaded manually, everytime after reboot.

  # kdump-config status
  current state   : Not ready to kdump

  
  ---uname output---
  Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux 
   
  Machine Type/Model = Power 8/8247-22L 

  Additional Info-
  # cat /proc/cmdline
  root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 
console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
   
  ---Steps to Reproduce---
  1. installed linux-crashdump
  2. edited the kdump-tools.cfg crashkernel cmdline to above
  3. update-grub
  4. reboot

  Expected:
  kdump-config to be loaded by default after reboot

  # kdump-config status
  current state   : Not ready to kdump

  # service kdump-tools status
  * kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: inactive (dead)

  ...
  https://github.com/systemd/systemd/issues/6334

  systemd in artful is not properly picking up the unit files in 
  /etc/systemd/system/default.target.wants

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1708409] Re: kdump service does not start after configure/reboot

2018-03-05 Thread Andrew Cloke
** Tags removed: triage-a
** Tags added: triage-g

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1708409

Title:
  kdump service does not start after configure/reboot

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

Bug description:
  == Comment: #0 - Harish Sriram  - 2017-08-02 01:45:01 ==
  kdump service does not start after configure/reboot

  --Problem Description---
  kdump service does not start after configure/reboot. It has to be 
started/loaded manually, everytime after reboot.

  # kdump-config status
  current state   : Not ready to kdump

  
  ---uname output---
  Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux 
   
  Machine Type/Model = Power 8/8247-22L 

  Additional Info-
  # cat /proc/cmdline
  root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 
console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
   
  ---Steps to Reproduce---
  1. installed linux-crashdump
  2. edited the kdump-tools.cfg crashkernel cmdline to above
  3. update-grub
  4. reboot

  Expected:
  kdump-config to be loaded by default after reboot

  # kdump-config status
  current state   : Not ready to kdump

  # service kdump-tools status
  * kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: inactive (dead)

  ...
  https://github.com/systemd/systemd/issues/6334

  systemd in artful is not properly picking up the unit files in 
  /etc/systemd/system/default.target.wants

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data

2018-03-05 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1732032

Title:
  ip maddr show and ip maddr show dev enP20p96s0 show different data

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

Bug description:
  [Impact]
  When a nic has a long enough name such that there is no space between the 
name and the ":" in /proc/net/igmp, ip maddr show dev  will miss the IPV4 
addresses which is otherwise shown with "ip maddr show".

  This is inconsistent behavior and can break scripts and tests, as
  shown in this bug's original description.

  Three patches from upstream were taken to fix this bug, and they were used 
individually instead of being merged into one single patch so it's easier to 
track and recognize authorship:
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=530903dd9003492edb0714e937ad4a5d1219e376
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=b48a1161f5f9b6a0cda399a224bbbf72eba4a5c6
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=21503ed2af233ffe795926f6641ac84ec1b15bf9

  [Test Case]
  * deploy the ubuntu release under test. Please use bare metal or a VM instead 
of containers, because the ip tool parses a file in /proc. Make sure iproute2 
is installed:
  sudo apt install iproute2

  * Run these commands to setup a dummy interface with a long name and
  an IPv4 address. Please change the address if it conflicts with a real
  network you might have available on that machine:

  sudo ip link add dummylongnic0 type dummy
  sudo ip addr add 192.168.199.10/24 dev dummylongnic0
  sudo ip link set dev dummylongnic0 up

  * Compare the output of these two commands with regards to the dummylongnic0 
interface:
  sudo ip maddr show
  sudo ip maddr show dev dummylongnic0

  * With the buggy iproute2 package installed, the more specific output "ip 
maddr show dev dummylongnic0" should lack the "inet 224.0.0.1" line:
  ip maddr show dev dummylongnic0
  2:dummylongnic0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
inet6 ff02::1
inet6 ff01::1

  
  Whereas the less specific command, which lists all interfaces, will have it 
listed for dummylongnic0:
  2:dummylongnic0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
inet  224.0.0.1
inet6 ff02::1
inet6 ff01::1

  
  * With the fixed iproute2 package, all dummylongnic0 addresses will be 
present in both outputs.

  
  [Regression Potential]
  In the end, the ip tool is parsing a text file produced by the kernel. As 
most parsing done in C, it's pretty low level and sensitive to changes in the 
file it's reading.

  [Other Info]
  I suggest to conduct the tests in VMs instead of containers (LXD) because the 
ip maddr command parses /proc/net/igmp, which is produced by the kernel. If you 
use a container, then it's the host's kernel that will be providing that file 
and it might not be the same as with the native kernel of that particular 
ubuntu release.

  --- Original description ---
  Attn. Canonical:  Please make sure that the existing iproute2 package gets 
updated with the two referenced patches as the missing information is impacting 
our standard test suites.

  Thanks.

  == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 ==
  ---Problem Description---
  ip maddr show and ip maddr show dev enP20p96s0 show different data

  ---uname output---
  Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = 8286-42A

  ---Steps to Reproduce---
   run these at command line:
  root@roselp1:~# ip maddr show
  ...
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet  224.0.0.252
  inet  224.0.0.1
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
  ...

  root@roselp1:~# ip maddr show dev enP20p96s0
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1

  == Comment: #12 - David Z. Dai  - 2017-11-13 15:07:32 ==

  I found upstream already 

[Touch-packages] [Bug 1733870] Re: [Ubuntu 18.10] Add GDB support to access/display POWER8 registers

2018-01-29 Thread Andrew Cloke
** Summary changed:

- [Ubuntu 18.04] Add GDB support to access/display POWER8 registers
+ [Ubuntu 18.10] Add GDB support to access/display POWER8 registers

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1733870

Title:
  [Ubuntu 18.10] Add GDB support to access/display POWER8 registers

Status in The Ubuntu-power-systems project:
  Incomplete
Status in gdb package in Ubuntu:
  Incomplete

Bug description:
  This feature request is for GDB support for access to Power registers
  that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM
  registers.

  The feature is currently being worked on, so no upstream code is
  available yet.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1742941] Re: zlib: improve crc32 performance on P8

2018-01-12 Thread Andrew Cloke
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => Low

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => David Britton (davidpbritton)

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1742941

Title:
  zlib: improve  crc32 performance on P8

Status in The Ubuntu-power-systems project:
  New
Status in zlib package in Ubuntu:
  New

Bug description:
  Calculate the checksum of data that is 16 byte aligned and a multiple
  of  16 bytes.

  The first step is to reduce it to 1024 bits. We do this in 8 parallel
   chunks in order to mask the latency of the vpmsum instructions. If we
   have more than 32 kB of data to checksum we repeat this step multiple
   times, passing in the previous 1024 bits.

   The next step is to reduce the 1024 bits to 64 bits. This step adds
   32 bits of 0s to the end - this matches what a CRC does. We just
   calculate constants that land the data in this 32 bits.

   We then use fixed point Barrett reduction to compute a mod n over GF(2)
   for n = CRC using POWER8 instructions. We use x = 32.

   http://en.wikipedia.org/wiki/Barrett_reduction

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2017-12-18 Thread Andrew Cloke
** Tags added: triage-g

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
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 Committed
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  Fix Committed
Status in audit source package in Zesty:
  Fix Committed

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:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1724152/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127

2017-12-04 Thread Andrew Cloke
Since this issue cannot be reproduced with 4.13, marking "invalid".

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1719720

Title:
  [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with
  exit code 127

Status in The Ubuntu-power-systems project:
  Invalid
Status in coreutils package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---
  Currently syslog is getting flooded with below log messages ..
  Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch 
/run/run.vpdd
  update' failed with exit code 127.

  This is on UBuntu 17.10 latest build.. 
   
  ---uname output---
  Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ZZ-L 

  ---Steps to Reproduce---
   I have seen these messages logged more often when we do any hotplug 
operations.. ex. cpu hotplug..

  Ok. .this is the continuation of LTC #144627 / Launchpad #1682774.

  As suggested in that bug, we did change udev script to create
  temporary file under /run and that patch is available in ubuntu 17.10.

  Looks like this is udev script issue. If I modify systemd-udevd like
  below it works fine.

  I've limited udev knowledge. I don't know if you have any other better
  solution to this issue.

  root@ltc-boston123:/lib/systemd/system# diff -Naurp  
systemd-udevd.service.org systemd-udevd.service
  --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500
  +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500
  @@ -25,7 +25,7 @@ KillMode=mixed
   WatchdogSec=3min
   TasksMax=infinity
   MountFlags=slave
  -MemoryDenyWriteExecute=yes
  +#MemoryDenyWriteExecute=yes
   RestrictRealtime=yes
   RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
   SystemCallArchitectures=native

  
  -Vasant

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data

2017-12-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1732032

Title:
  ip maddr show and ip maddr show dev enP20p96s0 show different data

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

Bug description:
  [Impact]
  When a nic has a long enough name such that there is no space between the 
name and the ":" in /proc/net/igmp, ip maddr show dev  will miss the IPV4 
addresses which is otherwise shown with "ip maddr show".

  This is inconsistent behavior and can break scripts and tests, as
  shown in this bug's original description.

  Three patches from upstream were taken to fix this bug, and they were used 
individually instead of being merged into one single patch so it's easier to 
track and recognize authorship:
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=530903dd9003492edb0714e937ad4a5d1219e376
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=b48a1161f5f9b6a0cda399a224bbbf72eba4a5c6
  
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=21503ed2af233ffe795926f6641ac84ec1b15bf9

  [Test Case]
  * deploy the ubuntu release under test. Please use bare metal or a VM instead 
of containers, because the ip tool parses a file in /proc. Make sure iproute2 
is installed:
  sudo apt install iproute2

  * Run these commands to setup a dummy interface with a long name and
  an IPv4 address. Please change the address if it conflicts with a real
  network you might have available on that machine:

  sudo ip link add dummylongnic0 type dummy
  sudo ip addr add 192.168.199.10/24 dev dummylongnic0
  sudo ip link set dev dummylongnic0 up

  * Compare the output of these two commands with regards to the dummylongnic0 
interface:
  sudo ip maddr show
  sudo ip maddr show dev dummylongnic0

  * With the buggy iproute2 package installed, the more specific output "ip 
maddr show dev dummylongnic0" should lack the "inet 224.0.0.1" line:
  ip maddr show dev dummylongnic0
  2:dummylongnic0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
inet6 ff02::1
inet6 ff01::1

  
  Whereas the less specific command, which lists all interfaces, will have it 
listed for dummylongnic0:
  2:dummylongnic0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
inet  224.0.0.1
inet6 ff02::1
inet6 ff01::1

  
  * With the fixed iproute2 package, all dummylongnic0 addresses will be 
present in both outputs.

  
  [Regression Potential]
  In the end, the ip tool is parsing a text file produced by the kernel. As 
most parsing done in C, it's pretty low level and sensitive to changes in the 
file it's reading.

  [Other Info]
  I suggest to conduct the tests in VMs instead of containers (LXD) because the 
ip maddr command parses /proc/net/igmp, which is produced by the kernel. If you 
use a container, then it's the host's kernel that will be providing that file 
and it might not be the same as with the native kernel of that particular 
ubuntu release.

  --- Original description ---
  Attn. Canonical:  Please make sure that the existing iproute2 package gets 
updated with the two referenced patches as the missing information is impacting 
our standard test suites.

  Thanks.

  == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 ==
  ---Problem Description---
  ip maddr show and ip maddr show dev enP20p96s0 show different data

  ---uname output---
  Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = 8286-42A

  ---Steps to Reproduce---
   run these at command line:
  root@roselp1:~# ip maddr show
  ...
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet  224.0.0.252
  inet  224.0.0.1
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
  ...

  root@roselp1:~# ip maddr show dev enP20p96s0
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1

  == Comment: #12 - David Z. Dai  - 2017-11-13 15:07:32 ==

  I found upstream already had patches that fix this problem:

  1) 

[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

2017-12-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Foundations Team 
(canonical-foundations)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732865

Title:
  [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min
  frequencies

Status in The Ubuntu-power-systems project:
  Triaged
Status in util-linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-01-03 
05:34:32 ==
  ---Problem Description---
  After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies
   
  Contact Information = ppaid...@in.ibm.com 
   
  ---uname output---
  Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 
UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = PowerNV 8284-22A 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Read lscpu output
  2. Inject HMI Non recoverable error three times
  3. Read lscpu output again
  compare the output cpu frequencies will list as NULL
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  Userspace tool common name: lscpu 

  Userspace rpm: util-linux 
   
  The userspace tool has the following bit modes: 64-bit 
   
  System Dump Info:
The system is not configured to capture a system dump.

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for ppaid...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of userspace application.

  
  Before CPU's are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):112
  On-line CPU(s) list:   0-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   4322.
  CPU min MHz:   2061.
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 0-31
  NUMA node1 CPU(s): 32-63
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  
  After 4 cores are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):96
  On-line CPU(s) list:   8-55,64-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   (null)
  CPU min MHz:   (null)
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 8-31
  NUMA node1 CPU(s): 32-55
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  == Comment: #1 - Pridhiviraj Paidipeddi  - 2017-01-11 
07:06:59 ==
  root@p8wookie:~# dmesg |grep -i powernv
  [0.00] Using PowerNV machine description
  [0.331564] EEH: PowerNV platform initialized
  [0.907250] powernv-rng: Registering arch random hook.
  [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
  [1.507167] powernv_idle_driver registered
  [   34.184048] powernv_rng: Registered powernv hwrng.
  [   34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
  [   34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, 
prod_id: 0x, dev_id: 0x00)
  root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
  [   42.297825315,7]   OCC Common Area at 0x3b0 size 1MB
  [   42.297854780,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297884305,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297914258,7]   OCC Common Area at 0x200080 size 1MB
  [   42.310897465,7] HBRT: OCC common base 00200080 : 0080
  [   42.317109440,7] HBRT: OCC common base 00200080 : 0080
  [   42.323969570,7] HBRT: OCC common base 00200080 : 0080
  [   42.330941943,7] HBRT: OCC common base 00200080 : 0080
  [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29
  [6.017413373,7] HBRT: OCC Load requested
  [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, 
occ_common_area 00200080, chip 
  [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, 
occ_common_area 00200080, chip 0001
  [6.017666150,7] HBRT: Calling loadOCC() homer 00280040, 
occ_common_area 00200080, chip 0010
  [6.017790110,7] 

[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data

2017-11-28 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1732032

Title:
  ip maddr show and ip maddr show dev enP20p96s0 show different data

Status in The Ubuntu-power-systems project:
  Triaged
Status in iproute2 package in Ubuntu:
  New

Bug description:
  Attn. Canonical:  Please make sure that the existing iproute2 package
  gets updated with the two referenced patches as the missing
  information is impacting our standard test suites.

  Thanks.

  == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 ==
  ---Problem Description---
  ip maddr show and ip maddr show dev enP20p96s0 show different data
   
  ---uname output---
  Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8286-42A 
   
  ---Steps to Reproduce---
   run these at command line:
  root@roselp1:~# ip maddr show
  ...
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet  224.0.0.252
  inet  224.0.0.1
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
  ...

  root@roselp1:~# ip maddr show dev enP20p96s0
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
   
  == Comment: #12 - David Z. Dai  - 2017-11-13 15:07:32 ==

  I found upstream already had patches that fix this problem:

  1) https://www.spinics.net/lists/netdev/msg415009.html
  commit 530903dd9003492edb0714e937ad4a5d1219e376
  Author: Petr Vorel 
  Date:   Tue Jan 17 00:25:50 2017 +0100

  ip: fix igmp parsing when iface is long

  Entries with long vhost names in /proc/net/igmp have no whitespace
  between name and colon, so sscanf() adds it to vhost and
  'ip maddr show iface' doesn't include inet result.

  Signed-off-by: Petr Vorel 

  
  2) https://www.spinics.net/lists/netdev/msg461479.html
  commit 21503ed2af233ffe795926f6641ac84ec1b15bf9
  Author: Michal Kubecek 
  Date:   Thu Oct 19 10:21:08 2017 +0200

  ip maddr: fix filtering by device

  Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses
  variable len to keep trailing colon from interface name comparison.  This
  variable is local to loop body but we set it in one pass and use it in
  following one(s) so that we are actually using (pseudo)random length for
  comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: 
Avoid
  accessing uninitialized data") always initializes len to zero so that the
  name comparison is always true. As a result, "ip maddr show dev eth0" 
shows
  IPv4 multicast addresses for all interfaces.

  Instead of keeping the length, let's simply replace the trailing colon 
with
  a null byte. The bonus is that we get correct interface name in ma.name.

  Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long")
  Signed-off-by: Michal Kubecek 
  Acked-by: Phil Sutter 
  Acked-by: Petr Vorel 

  The fix is in the same place, but different way.
  This is the current implementation In ip/ipmaddr.c file:
  struct ma_info *ma;

  if (buf[0] != '\t') {
  size_t len;

  sscanf(buf, "%d%s", , m.name);
  len = strlen(m.name);
  if (m.name[len - 1] == ':')
  m.name[len - 1] = '\0';
  continue;
  }

  
  The existing "ip" command that shows the problem:
  [root@coral-sriov-host1 ip]# /usr/sbin/ip maddr show dev enP1p12s0f0   /* <-- 
We do NOT see the IPv4 maddr */
  2:  enP1p12s0f0
  link  01:00:5e:00:00:01
  inet6 ff02::1
  inet6 ff01::1

  I clone the latest "ip" utility from upstream to the same test box.
  [root@coral-sriov-host1 git_iproute2]# git clone 
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

  I build the "ip" utility on same test box, which has the above 2
  patches included.

  [root@coral-sriov-host1 ip]# /root/git_iproute2/iproute2/ip/ip maddr show dev 
enP1p12s0f0  /* <--- shows correct IPv4 maddr */
  2:  enP1p12s0f0
  link  01:00:5e:00:00:01
  inet  224.0.0.1/* <--- */
  inet6 ff02::1
  inet6 ff01::1

To manage notifications about this bug go to:

[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

2017-11-28 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732865

Title:
  [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min
  frequencies

Status in The Ubuntu-power-systems project:
  Triaged
Status in util-linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-01-03 
05:34:32 ==
  ---Problem Description---
  After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies
   
  Contact Information = ppaid...@in.ibm.com 
   
  ---uname output---
  Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 
UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = PowerNV 8284-22A 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Read lscpu output
  2. Inject HMI Non recoverable error three times
  3. Read lscpu output again
  compare the output cpu frequencies will list as NULL
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  Userspace tool common name: lscpu 

  Userspace rpm: util-linux 
   
  The userspace tool has the following bit modes: 64-bit 
   
  System Dump Info:
The system is not configured to capture a system dump.

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for ppaid...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of userspace application.

  
  Before CPU's are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):112
  On-line CPU(s) list:   0-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   4322.
  CPU min MHz:   2061.
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 0-31
  NUMA node1 CPU(s): 32-63
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  
  After 4 cores are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):96
  On-line CPU(s) list:   8-55,64-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   (null)
  CPU min MHz:   (null)
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 8-31
  NUMA node1 CPU(s): 32-55
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  == Comment: #1 - Pridhiviraj Paidipeddi  - 2017-01-11 
07:06:59 ==
  root@p8wookie:~# dmesg |grep -i powernv
  [0.00] Using PowerNV machine description
  [0.331564] EEH: PowerNV platform initialized
  [0.907250] powernv-rng: Registering arch random hook.
  [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
  [1.507167] powernv_idle_driver registered
  [   34.184048] powernv_rng: Registered powernv hwrng.
  [   34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
  [   34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, 
prod_id: 0x, dev_id: 0x00)
  root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
  [   42.297825315,7]   OCC Common Area at 0x3b0 size 1MB
  [   42.297854780,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297884305,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297914258,7]   OCC Common Area at 0x200080 size 1MB
  [   42.310897465,7] HBRT: OCC common base 00200080 : 0080
  [   42.317109440,7] HBRT: OCC common base 00200080 : 0080
  [   42.323969570,7] HBRT: OCC common base 00200080 : 0080
  [   42.330941943,7] HBRT: OCC common base 00200080 : 0080
  [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29
  [6.017413373,7] HBRT: OCC Load requested
  [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, 
occ_common_area 00200080, chip 
  [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, 
occ_common_area 00200080, chip 0001
  [6.017666150,7] HBRT: Calling loadOCC() homer 00280040, 
occ_common_area 00200080, chip 0010
  [6.017790110,7] HBRT: Calling loadOCC() homer 00100040, 

[Touch-packages] [Bug 1708409] Re: kdump service does not start after configure/reboot

2017-11-28 Thread Andrew Cloke
** Tags added: ppc64el-kdump

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1708409

Title:
  kdump service does not start after configure/reboot

Status in The Ubuntu-power-systems project:
  Triaged
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Triaged
Status in makedumpfile source package in Artful:
  New
Status in systemd source package in Artful:
  New
Status in makedumpfile source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Triaged

Bug description:
  == Comment: #0 - Harish Sriram  - 2017-08-02 01:45:01 ==
  kdump service does not start after configure/reboot

  --Problem Description---
  kdump service does not start after configure/reboot. It has to be 
started/loaded manually, everytime after reboot.

  # kdump-config status
  current state   : Not ready to kdump

  
  ---uname output---
  Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux 
   
  Machine Type/Model = Power 8/8247-22L 

  Additional Info-
  # cat /proc/cmdline
  root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 
console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
   
  ---Steps to Reproduce---
  1. installed linux-crashdump
  2. edited the kdump-tools.cfg crashkernel cmdline to above
  3. update-grub
  4. reboot

  Expected:
  kdump-config to be loaded by default after reboot

  # kdump-config status
  current state   : Not ready to kdump

  # service kdump-tools status
  * kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: inactive (dead)

  ...
  https://github.com/systemd/systemd/issues/6334

  systemd in artful is not properly picking up the unit files in 
  /etc/systemd/system/default.target.wants

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1699759] Re: LXC Alpine template broken on ppc64le

2017-11-28 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1699759

Title:
  LXC Alpine template broken on ppc64le

Status in The Ubuntu-power-systems project:
  Fix Released
Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #0 - Breno Leitao  - 2017-06-14 07:36:33 ==
  LXC Alpine template is broken on Ubuntu 17.10, since it does not support 
ppc64le.

  It shows the following message:

  # Unknown architecture.

  == Comment: #1 - Breno Leitao  - 2017-06-14 07:37:50 ==
  Patch sent to upstream and accepted already:

  https://github.com/lxc/lxc/pull/1621#issuecomment-307887344

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1719579] Re: [Ubuntu 16.04.2] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save

2017-11-20 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1719579

Title:
  [Ubuntu 16.04.2] [libvirt] virsh restore fails from state file saved
  in /var/tmp folder using virsh save

Status in The Ubuntu-power-systems project:
  Incomplete
Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #1 - SEETEENA THOUFEEK  - 2017-01-17 
00:09:16 ==
  Bala, Please mail me the machine information.

  == Comment: #3 - SEETEENA THOUFEEK  - 2017-01-17 
02:14:06 ==
  2017-01-16 12:09:37.707+: 7024: info : 
virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on 
'/var/tmp/bala'
  2017-01-16 12:09:37.707+: 7024: info : 
virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on 
'/var/tmp/bala' to '0:0'
  2017-01-16 12:09:37.707+: 7024: warning : qemuDomainSaveImageStartVM:6750 
: failed to restore save state label on /var/tmp/bala
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: debug : qemuDomainObjEndAsyncJob:1848 : 
Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala)
  2017-01-16 12:09:37.707+: 7024: info : virObjectRef:296 : OBJECT_REF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca62b00
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff4ca535c0
  2017-01-16 12:09:37.707+: 7024: debug : virThreadJobClear:121 : Thread 
7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with 
ret=-1
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff7c002c10
  2017-01-16 12:09:37.707+: 7024: debug : virNetServerProgramSendError:153 
: prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590 
rerr=0x3fffa59be3c0
  2017-01-16 12:09:37.707+: 7024: debug : virNetMessageEncodePayload:376 : 
Encode length as 172
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172 
offset=0
  2017-01-16 12:09:37.707+: 7024: info : 
virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: 
client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1 
serial=4
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670 
tx=0x100133d2590
  2017-01-16 12:09:37.707+: 7024: debug : 
virNetServerClientCalculateHandleMode:192 : mode=3
  2017-01-16 12:09:37.707+: 7024: info : virEventPollUpdateHandle:152 : 
EVENT_POLL_UPDATE_HANDLE: watch=417 events=3
  2017-01-16 12:09:37.707+: 7024: debug : virEventPollInterruptLocked:727 : 
Interrupting
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x3fff7c002c10
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x100133caea0
  2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x100133d23c0
  .
  2017-01-16 12:14:28.445+: 7019: info : qemuMonitorJSONIOProcessLine:201 : 
QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds": 
1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status": 
"failed"}}
  2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorJSONIOProcessEvent:147 
: mon=0x3fff94004d90 obj=0x100133b5670
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1762 : 
object=0x100133a8000
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : 
object=0x100133a8000 type=0 gen=0x100133d1160
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : 
object=0x100133d2a80 type=2 gen=0x100133d1160
  2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1795 : 
result={"status":"failed"}
  2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorEmitEvent:1218 : 
mon=0x3fff94004d90 event=MIGRATION
  2017-01-16 12:14:28.445+: 7019: info : virObjectRef:296 : OBJECT_REF: 
obj=0x3fff94004d90
  2017-01-16 12:14:28.445+: 7019: debug : qemuProcessHandleEvent:629 : 
vm=0x3fff4ca535c0
  2017-01-16 12:14:28.445+: 7019: info : virObjectNew:202 : OBJECT_NEW: 
obj=0x100133d2870 classname=virDomainQemuMonitorEvent
  2017-01-16 12:14:28.445+: 7019: debug : virObjectEventNew:645 : 
obj=0x100133d2870
  2017-01-16 12:14:28.445+: 7019: info : virObjectUnref:259 : OBJECT_UNREF: 
obj=0x100133d2870
  2017-01-16 12:14:28.445+: 7019: info : virObjectUnref:261 : 
OBJECT_DISPOSE: obj=0x100133d2870
  2017-01-16 12:14:28.445+: 7019: debug : 
virDomainQemuMonitorEventDispose:477 : obj=0x100133d2870
  2017-01-16 12:14:28.445+: 7019: debug : 

[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127

2017-11-20 Thread Andrew Cloke
** Tags added: triage-g

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1719720

Title:
  [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with
  exit code 127

Status in The Ubuntu-power-systems project:
  Triaged
Status in coreutils package in Ubuntu:
  Triaged

Bug description:
  ---Problem Description---
  Currently syslog is getting flooded with below log messages ..
  Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch 
/run/run.vpdd
  update' failed with exit code 127.

  This is on UBuntu 17.10 latest build.. 
   
  ---uname output---
  Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ZZ-L 

  ---Steps to Reproduce---
   I have seen these messages logged more often when we do any hotplug 
operations.. ex. cpu hotplug..

  Ok. .this is the continuation of LTC #144627 / Launchpad #1682774.

  As suggested in that bug, we did change udev script to create
  temporary file under /run and that patch is available in ubuntu 17.10.

  Looks like this is udev script issue. If I modify systemd-udevd like
  below it works fine.

  I've limited udev knowledge. I don't know if you have any other better
  solution to this issue.

  root@ltc-boston123:/lib/systemd/system# diff -Naurp  
systemd-udevd.service.org systemd-udevd.service
  --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500
  +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500
  @@ -25,7 +25,7 @@ KillMode=mixed
   WatchdogSec=3min
   TasksMax=infinity
   MountFlags=slave
  -MemoryDenyWriteExecute=yes
  +#MemoryDenyWriteExecute=yes
   RestrictRealtime=yes
   RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
   SystemCallArchitectures=native

  
  -Vasant

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

2017-11-20 Thread Andrew Cloke
Apologies, initially misdirected to kernel team. We believe util-linux
is owned by server team. Please advise if that is not correct.

** Changed in: ubuntu-power-systems
 Assignee: Canonical Kernel Team (canonical-kernel-team) => David Britton 
(davidpbritton)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732865

Title:
  [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min
  frequencies

Status in The Ubuntu-power-systems project:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-01-03 
05:34:32 ==
  ---Problem Description---
  After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies
   
  Contact Information = ppaid...@in.ibm.com 
   
  ---uname output---
  Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 
UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = PowerNV 8284-22A 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Read lscpu output
  2. Inject HMI Non recoverable error three times
  3. Read lscpu output again
  compare the output cpu frequencies will list as NULL
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  Userspace tool common name: lscpu 

  Userspace rpm: util-linux 
   
  The userspace tool has the following bit modes: 64-bit 
   
  System Dump Info:
The system is not configured to capture a system dump.

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for ppaid...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of userspace application.

  
  Before CPU's are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):112
  On-line CPU(s) list:   0-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   4322.
  CPU min MHz:   2061.
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 0-31
  NUMA node1 CPU(s): 32-63
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  
  After 4 cores are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):96
  On-line CPU(s) list:   8-55,64-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   (null)
  CPU min MHz:   (null)
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 8-31
  NUMA node1 CPU(s): 32-55
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  == Comment: #1 - Pridhiviraj Paidipeddi  - 2017-01-11 
07:06:59 ==
  root@p8wookie:~# dmesg |grep -i powernv
  [0.00] Using PowerNV machine description
  [0.331564] EEH: PowerNV platform initialized
  [0.907250] powernv-rng: Registering arch random hook.
  [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
  [1.507167] powernv_idle_driver registered
  [   34.184048] powernv_rng: Registered powernv hwrng.
  [   34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
  [   34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, 
prod_id: 0x, dev_id: 0x00)
  root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
  [   42.297825315,7]   OCC Common Area at 0x3b0 size 1MB
  [   42.297854780,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297884305,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297914258,7]   OCC Common Area at 0x200080 size 1MB
  [   42.310897465,7] HBRT: OCC common base 00200080 : 0080
  [   42.317109440,7] HBRT: OCC common base 00200080 : 0080
  [   42.323969570,7] HBRT: OCC common base 00200080 : 0080
  [   42.330941943,7] HBRT: OCC common base 00200080 : 0080
  [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29
  [6.017413373,7] HBRT: OCC Load requested
  [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, 
occ_common_area 00200080, chip 
  [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, 
occ_common_area 00200080, chip 

[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data

2017-11-20 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
 Assignee: Canonical Server Team (canonical-server) => David Britton 
(davidpbritton)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1732032

Title:
  ip maddr show and ip maddr show dev enP20p96s0 show different data

Status in The Ubuntu-power-systems project:
  New
Status in iproute2 package in Ubuntu:
  New

Bug description:
  Attn. Canonical:  Please make sure that the existing iproute2 package
  gets updated with the two referenced patches as the missing
  information is impacting our standard test suites.

  Thanks.

  == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 ==
  ---Problem Description---
  ip maddr show and ip maddr show dev enP20p96s0 show different data
   
  ---uname output---
  Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8286-42A 
   
  ---Steps to Reproduce---
   run these at command line:
  root@roselp1:~# ip maddr show
  ...
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet  224.0.0.252
  inet  224.0.0.1
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
  ...

  root@roselp1:~# ip maddr show dev enP20p96s0
  10: enP20p96s0
  link  33:33:00:00:00:01
  link  01:00:5e:00:00:01
  link  33:33:ff:6d:d0:d0
  link  01:00:5e:00:00:fc
  link  33:33:00:01:00:03
  inet6 ff02::1:3
  inet6 ff02::1:ff6d:d0d0 users 3
  inet6 ff02::1
  inet6 ff01::1
   
  == Comment: #12 - David Z. Dai  - 2017-11-13 15:07:32 ==

  I found upstream already had patches that fix this problem:

  1) https://www.spinics.net/lists/netdev/msg415009.html
  commit 530903dd9003492edb0714e937ad4a5d1219e376
  Author: Petr Vorel 
  Date:   Tue Jan 17 00:25:50 2017 +0100

  ip: fix igmp parsing when iface is long

  Entries with long vhost names in /proc/net/igmp have no whitespace
  between name and colon, so sscanf() adds it to vhost and
  'ip maddr show iface' doesn't include inet result.

  Signed-off-by: Petr Vorel 

  
  2) https://www.spinics.net/lists/netdev/msg461479.html
  commit 21503ed2af233ffe795926f6641ac84ec1b15bf9
  Author: Michal Kubecek 
  Date:   Thu Oct 19 10:21:08 2017 +0200

  ip maddr: fix filtering by device

  Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses
  variable len to keep trailing colon from interface name comparison.  This
  variable is local to loop body but we set it in one pass and use it in
  following one(s) so that we are actually using (pseudo)random length for
  comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: 
Avoid
  accessing uninitialized data") always initializes len to zero so that the
  name comparison is always true. As a result, "ip maddr show dev eth0" 
shows
  IPv4 multicast addresses for all interfaces.

  Instead of keeping the length, let's simply replace the trailing colon 
with
  a null byte. The bonus is that we get correct interface name in ma.name.

  Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long")
  Signed-off-by: Michal Kubecek 
  Acked-by: Phil Sutter 
  Acked-by: Petr Vorel 

  The fix is in the same place, but different way.
  This is the current implementation In ip/ipmaddr.c file:
  struct ma_info *ma;

  if (buf[0] != '\t') {
  size_t len;

  sscanf(buf, "%d%s", , m.name);
  len = strlen(m.name);
  if (m.name[len - 1] == ':')
  m.name[len - 1] = '\0';
  continue;
  }

  
  The existing "ip" command that shows the problem:
  [root@coral-sriov-host1 ip]# /usr/sbin/ip maddr show dev enP1p12s0f0   /* <-- 
We do NOT see the IPv4 maddr */
  2:  enP1p12s0f0
  link  01:00:5e:00:00:01
  inet6 ff02::1
  inet6 ff01::1

  I clone the latest "ip" utility from upstream to the same test box.
  [root@coral-sriov-host1 git_iproute2]# git clone 
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

  I build the "ip" utility on same test box, which has the above 2
  patches included.

  [root@coral-sriov-host1 ip]# /root/git_iproute2/iproute2/ip/ip maddr show dev 
enP1p12s0f0  /* <--- shows correct IPv4 maddr */
  2:  enP1p12s0f0
  link  01:00:5e:00:00:01
  inet  224.0.0.1/* <--- */
  inet6 ff02::1
  inet6 

[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

2017-11-17 Thread Andrew Cloke
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

** Tags added: triage-g

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732865

Title:
  [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min
  frequencies

Status in The Ubuntu-power-systems project:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Pridhiviraj Paidipeddi  - 2017-01-03 
05:34:32 ==
  ---Problem Description---
  After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies
   
  Contact Information = ppaid...@in.ibm.com 
   
  ---uname output---
  Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 
UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = PowerNV 8284-22A 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Read lscpu output
  2. Inject HMI Non recoverable error three times
  3. Read lscpu output again
  compare the output cpu frequencies will list as NULL
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  Userspace tool common name: lscpu 

  Userspace rpm: util-linux 
   
  The userspace tool has the following bit modes: 64-bit 
   
  System Dump Info:
The system is not configured to capture a system dump.

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for ppaid...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.
  -Attach ltrace and strace of userspace application.

  
  Before CPU's are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):112
  On-line CPU(s) list:   0-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   4322.
  CPU min MHz:   2061.
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 0-31
  NUMA node1 CPU(s): 32-63
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  
  After 4 cores are garded:
  root@p8wookie:~# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):96
  On-line CPU(s) list:   8-55,64-71,80-103,112-127
  Thread(s) per core:8
  Core(s) per socket:3
  Socket(s): 4
  NUMA node(s):  4
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8E (raw), altivec supported
  CPU max MHz:   (null)
  CPU min MHz:   (null)
  L1d cache: 64K
  L1i cache: 32K
  L2 cache:  512K
  L3 cache:  8192K
  NUMA node0 CPU(s): 8-31
  NUMA node1 CPU(s): 32-55
  NUMA node16 CPU(s):64-71,80-95
  NUMA node17 CPU(s):96-103,112-127

  == Comment: #1 - Pridhiviraj Paidipeddi  - 2017-01-11 
07:06:59 ==
  root@p8wookie:~# dmesg |grep -i powernv
  [0.00] Using PowerNV machine description
  [0.331564] EEH: PowerNV platform initialized
  [0.907250] powernv-rng: Registering arch random hook.
  [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
  [1.507167] powernv_idle_driver registered
  [   34.184048] powernv_rng: Registered powernv hwrng.
  [   34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
  [   34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, 
prod_id: 0x, dev_id: 0x00)
  root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
  [   42.297825315,7]   OCC Common Area at 0x3b0 size 1MB
  [   42.297854780,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297884305,7]   OCC Common Area at 0x200080 size 1MB
  [   42.297914258,7]   OCC Common Area at 0x200080 size 1MB
  [   42.310897465,7] HBRT: OCC common base 00200080 : 0080
  [   42.317109440,7] HBRT: OCC common base 00200080 : 0080
  [   42.323969570,7] HBRT: OCC common base 00200080 : 0080
  [   42.330941943,7] HBRT: OCC common base 00200080 : 0080
  [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29
  [6.017413373,7] HBRT: OCC Load requested
  [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, 
occ_common_area 00200080, chip 
  [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, 

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

2017-10-18 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
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:
  In Progress
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  In Progress
Status in audit source package in Zesty:
  In Progress

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:

[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127

2017-09-26 Thread Andrew Cloke
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

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

** Changed in: ubuntu-power-systems
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1719720

Title:
  [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with
  exit code 127

Status in The Ubuntu-power-systems project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  Currently syslog is getting flooded with below log messages ..
  Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch 
/run/run.vpdd
  update' failed with exit code 127.

  This is on UBuntu 17.10 latest build.. 
   
  ---uname output---
  Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 
2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ZZ-L 

  ---Steps to Reproduce---
   I have seen these messages logged more often when we do any hotplug 
operations.. ex. cpu hotplug..

  Ok. .this is the continuation of LTC #144627 / Launchpad #1682774.

  As suggested in that bug, we did change udev script to create
  temporary file under /run and that patch is available in ubuntu 17.10.

  Looks like this is udev script issue. If I modify systemd-udevd like
  below it works fine.

  I've limited udev knowledge. I don't know if you have any other better
  solution to this issue.

  root@ltc-boston123:/lib/systemd/system# diff -Naurp  
systemd-udevd.service.org systemd-udevd.service
  --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500
  +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500
  @@ -25,7 +25,7 @@ KillMode=mixed
   WatchdogSec=3min
   TasksMax=infinity
   MountFlags=slave
  -MemoryDenyWriteExecute=yes
  +#MemoryDenyWriteExecute=yes
   RestrictRealtime=yes
   RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
   SystemCallArchitectures=native

  
  -Vasant

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1706948] Re: [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils

2017-09-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: New => Incomplete

** Changed in: pm-utils (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1706948

Title:
  [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by
  systemd and pm-utils

Status in The Ubuntu-power-systems project:
  Incomplete
Status in pm-utils package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 ==
  systemd and pm-utils interprets CanSuspend states differently and reports it 
as supported or not in a conflicting way.

  # gdbus call --system --dest org.freedesktop.login1 --object-path 
/org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend
  ('yes',)

  # pm-is-supported --suspend
  # echo $?
  1

  Both systemd and pm-is-supported looks into /sys/power/state file to
  check if suspend is supported.

  pm-is-supported --suspend returns true if either "standby" or "mem" is 
present in the file.
  ( /usr/lib/pm-utils/pm-functions )

  systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is 
present in the file.
  ( 
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c
 )

  # cat /sys/power/state
  freeze

  So here, pm-is-supported --suspend returns false and gdbus returns
  true.

  Both these utilities interpret /sys/power/state differently.

  Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or
  don't report freeze as CanSuspend.

  Impact of this inconsistency can be felt from Libvirt supported pm
  states:

  To reduce ABI dependency, libvirt queries the available states via
  dbus, if not falls to pm-utils. Libvirt won't check for strings in
  sys/power/state and interpret directly.

  so due to this, libvirt will list that suspend_to_mem is supported
  from virsh capabilities but ideally it might not.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1651518] Re: systemd/logind parsing problem: HTX exercisers stopped on error: rc 11, errno 11 from main(): pthread_create

2017-09-04 Thread Andrew Cloke
** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
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:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
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 htxlogindcustom.conf
  

[Touch-packages] [Bug 1713536] Re: udev: boot script does not trigger subsystem coldplug

2017-08-29 Thread Andrew Cloke
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => Medium

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1713536

Title:
  udev: boot script does not trigger subsystem coldplug

Status in The Ubuntu-power-systems project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  The udev initramfs-tools boot script does not trigger subsystem "add"
  uevents. As a result, udev rules that listen to subsystem "add" events
  are never activated. This problem exists on at least Ubuntu 16.04 and
  17.10.

  On s390, this results in a boot failure if the kernel is configured to
  start with an active device black list (kernel parameter
  cio_ignore=all,!condev). An example for an affected udev rule looks
  like this:

  ACTION=="add", SUBSYSTEM=="subsystem", KERNEL=="ccw",
  RUN{program}+="/bin/sh -c 'echo free 0009,ec30,ec32,f5f0-f5f2 >
  /proc/cio_ignore'"

  A proposed fix would be:

  Modify /usr/share/initramfs-tools/scripts/init-top/udev:

  Replace line
  udevadm trigger --action=add
  with
  udevadm trigger --type=subsystems --action=add
  udevadm trigger --type=devices --action=add

  This would also be consistent with the steps that the systemd udev
  coldplug unit file performs (see /lib/systemd/system/systemd-udev-
  trigger.service).

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1623383] Re: Some restarts fail due to missing base devices

2017-05-17 Thread Andrew Cloke
Hi, we’re trying to explore different approaches to investigate, resolve
and/or work around this issue, but regrettably there do not appear to be
any simple solutions.

Would it be possible to record the failure rate during the testing for
the next SRU cycle? Perhaps something simple like “5 failures in 50
redeployments over a 2 week period”?

Many thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1623383

Title:
  Some restarts fail due to missing base devices

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Arch: s390x
  Release: Yakkety / 16.10

  This happens on some (but not all) system starts with Yakkety. In
  Xenial (which is using the same 4.4 kernel version the Yakkety systems
  were using when the problem was first observed) this did not happen.
  The system (LPAR) this was seen first was an upgrade from Xenial but
  since then has been freshly installed with Yakkety. The same behaviour
  is seen on a zVM guest running Yakkety.

  The attached syslog shows a failed boot, followed by one that did work. Note 
the "Found device .*(sclp|encc00).*" messages in the good boot. Those are 
missing in the bad attempt and as a result networking and console fail to be 
usable. Also note, those boots were 4.8 kernels but we saw this with 4.4 
kernels, too.
  This might be a systemd problem / race, I just filed it into udev for now as 
that better matches the not finding basic devices symptom.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1625319] Re: [LTCTest] SR-IOV VF hotplug failing: cannot limit locked memory of process

2017-02-27 Thread Andrew Cloke
As per comment #5, marking as "Fix Released".

** Changed in: apparmor (Ubuntu)
   Status: Incomplete => Fix Released

** Changed in: apparmor (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1625319

Title:
  [LTCTest] SR-IOV VF hotplug failing: cannot limit locked memory of
  process

Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  ---Problem Description---
  Unable to hotplug SRIOV CX4 VF to Ubuntu 16.10 or 16.04.1 guests.

  ---uname output---
  Linux c158f2u09os 4.7.0unofficial #5 SMP Mon Sep 5 08:53:38 EDT 2016 ppc64le 
ppc64le ppc64le GNU/Linux
   
  ---Additional Hardware Info---
  Mellanox CX4 

  Machine Type = 8247-22L 

  ---Steps to Reproduce---
   Unable to hotplug SRIOV CX4 VF to Ubuntu 16.10 guest.

  1. Boot the guests with/without VFs
  2. Try hotplugging of VF to guests, you will notice error as shown below:

  root@c158f2u09os:/var/lib/libvirt/images/srikanth# cat hot_vf.xml 
  

  

  
  root@c158f2u09os:/var/lib/libvirt/images/srikanth# virsh attach-device 
ubuntu1610_srik ./hot_vf.xml --live
  error: Failed to attach device from ./hot_vf.xml
  error: cannot limit locked memory of process 80265 to 9663676416: Permission 
denied

  root@c158f2u09os:/var/lib/libvirt/images/srikanth# virsh attach-device 
ubuntu160401_srik ./hot_vf.xml --live
  error: Failed to attach device from ./hot_vf.xml
  error: cannot limit locked memory of process 80960 to 9663676416: Permission 
denied

  =
  Environment details:
  =

  Host : 
9.47.68.198, root/sriov4321
Ubuntu 16.10
kernel version: 
Linux c158f2u09os 4.7.0unofficial #5 SMP Mon Sep 5 08:53:38 EDT 2016 
ppc64le ppc64le ppc64le GNU/Linux
  Guest: 
  1. ubuntu1610_srik
kernel version: 4.7.0unofficial
creds: root/123456
  2. ubuntu160401_srik
kernel version: 4.4.0-38-generic
creds: root/123456

  MOFED versions:
MOFED version in Host as well Guest: 3.4-OFED.3.4.0.1.0.1
CX4 Firmware version: 12.17.0222

  Development took a look at this an believes this is an apparmor
  related issue and requested the defect be mirrored to Canonical for
  their assistance.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1653489] Re: [LTCTest][OPAL][FW860.20] Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu 16.04.1 is dropping to (initramfs)

2017-01-30 Thread Andrew Cloke
** Changed in: initramfs-tools (Ubuntu)
 Assignee: Taco Screen team (taco-screen-team) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1653489

Title:
  [LTCTest][OPAL][FW860.20] Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu
  16.04.1 is dropping to (initramfs)

Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  @kernel-team

  Please move ipr module from image-extra to image package.


  ---Problem Description---
  Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu 16.04.1 is dropping to (initramfs)

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

  ---uname output---
  Linux (none) 4.8.0-27-generic #29~16.04.1-Ubuntu SMP Fri Nov 4 17:24:37 UTC 
2016 ppc64le GNU/Linux

  ---Additional Hardware Info---
  root@powerkvm3-lp1:~# lspci
  :00:00.0 PCI bridge: IBM Device 03dc
  :01:00.0 RAID bus controller: IBM Obsidian-E PCI-E SCSI controller (rev 
01)
  0001:00:00.0 PCI bridge: IBM Device 03dc
  0001:01:00.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI 
Express Gen 3 (8.0 GT/s) Switch (rev ca)
  0001:02:01.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI 
Express Gen 3 (8.0 GT/s) Switch (rev ca)
  0001:02:08.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI 
Express Gen 3 (8.0 GT/s) Switch (rev ca)
  0001:02:09.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI 
Express Gen 3 (8.0 GT/s) Switch (rev ca)
  0001:03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0001:03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0001:03:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0001:03:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0001:04:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) (rev 01)
  0001:05:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) (rev 01)
  0004:00:00.0 PCI bridge: IBM Device 03dc
  0004:01:00.0 Fibre Channel: Emulex Corporation Lancer-X: LightPulse Fibre 
Channel Host Adapter (rev 10)
  0004:01:00.1 Fibre Channel: Emulex Corporation Lancer-X: LightPulse Fibre 
Channel Host Adapter (rev 10)
  0005:00:00.0 PCI bridge: IBM Device 03dc
  0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:02:01.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:02:08.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:02:09.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:02:10.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:02:11.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca)
  0005:03:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 
xHCI Host Controller (rev 02)
  0005:09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0005:09:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0005:09:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0005:09:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0005:0f:00.0 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre 
Channel Host Adapter (rev 03)
  0005:0f:00.1 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre 
Channel Host Adapter (rev 03)
  0040:00:00.0 PCI bridge: IBM Device 03dc
  0044:00:00.0 PCI bridge: IBM Device 03dc
  0044:01:00.0 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) 
(rev 10)
  0044:01:00.1 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) 
(rev 10)
  0044:01:00.2 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) 
(rev 10)
  0044:01:00.3 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) 
(rev 10)
  0044:01:00.4 Fibre Channel: Emulex Corporation OneConnect FCoE Initiator 
(Lancer) (rev 10)
  0044:01:00.5 Fibre Channel: Emulex Corporation OneConnect FCoE Initiator 
(Lancer) (rev 10)
  0045:00:00.0 PCI bridge: IBM Device 03dc
  0045:01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0045:01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0045:01:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)
  0045:01:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 
Gigabit Ethernet PCIe (rev 01)

  Machine Type = P8

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

  ---Steps to Reproduce---
   Install Ubuntu 16.04.1 OS using netboot images.
  Then upgrade the kernel by Installing the kernel 4.8 on the same.
  After upgrading the kernel, we are 

[Touch-packages] [Bug 1584602] Re: internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336

2016-05-24 Thread Andrew Cloke
I've raised https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1585174
to highlight the issue and suggest using the "-fno-if-conversion" option
that Matthias has identifed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu.
https://bugs.launchpad.net/bugs/1584602

Title:
  internal compiler error: in fixup_reorder_chain,,  at cfgrtl.c:3336

Status in gcc-4.8 package in Ubuntu:
  Confirmed

Bug description:
  When building samba package on trusty/arm64 with gcc-4.8, the
  following build crash can be observed, and it can be triggered with
  gcc-4.7 too.

  
  01:07:10 runner /usr/bin/gcc -g -O2 -fstack-protector 
--param=ssp-buffer-size=4
  -Wformat -Werror=format-security -fPIC -D_REENTRANT
  -D_POSIX_PTHREAD_SEMANTICS --
  DSTATIC_LOCKING_MODULES=NULL -DSTATIC_LOCKING_MODULES_PROTO=extern
  void __LOCKINN
  G_dummy_module_proto(void) -MD -D_FORTIFY_SOURCE=2 -Idefault/source3
  -I../sourcee
  3 -Idefault/source3/include -I../source3/include -Idefault/source3/lib
  -I../sourr
  ce3/lib -Idefault/source4/heimdal/lib/com_err
  -I../source4/heimdal/lib/com_err --
  Idefault/source4/heimdal/lib/krb5 -I../source4/heimdal/lib/krb5
  -Idefault/sourcee
  4/heimdal/lib/gssapi -I../source4/heimdal/lib/gssapi
  -Idefault/source4/heimdal_bb
  uild -I../source4/heimdal_build
  -Idefault/bin/default/source4/heimdal/lib/asn1 --
  Idefault/source4/heimdal/lib/asn1 -Idefault/include/public
  -I../include/public --
  Idefault/source4 -I../source4 -Idefault/lib -I../lib
  -Idefault/source4/lib -I..//
  source4/lib -Idefault/source4/include -I../source4/include
  -Idefault/include -I..
  ./include -Idefault/lib/replace -I../lib/replace -Idefault -I..
  -Idefault/librpcc
   -I../librpc -Idefault/libcli/security -I../libcli/security
  -Idefault/source3/lii
  brpc -I../source3/librpc -Idefault/libcli/util -I../libcli/util
  -Idefault/lib/utt
  il/charset -I../lib/util/charset -Idefault/dynconfig -I../dynconfig
  -Idefault/lii
  b/compression -I../lib/compression -Idefault/libcli/nbt
  -I../libcli/nbt -Idefaull
  t/lib/crypto -I../lib/crypto -I/usr/local/include -D_SAMBA_BUILD_=4
  -DHAVE_CONFII
  G_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 ../source3/locking/brlock.c 
-c
  -o default/source3/locking/brlock_92.o
  ../source3/smbd/notify.c: In function ‘change_notify_create’:
  ../source3/smbd/notify.c:297:1: internal compiler error: in
  fixup_reorder_chain,,
   at cfgrtl.c:3336
  ../source3/smbd/notify.c: In function ‘change_notify_create’:
  ../source3/smbd/notify.c:297:1: internal compiler error: in
  fixup_reorder_chain,,
   at cfgrtl.c:3336
   }
   ^
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1584602/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1464442] Re: installing or upgrading libc6 in Trusty removes all content from /tmp directory

2015-06-17 Thread Andrew Cloke
This bug is also effecting the MAAS 1.7.1 deployment of Ubuntu 14.04
onto a diskless server with access to iSCSI LUN, as described in
https://bugs.launchpad.net/curtin/+bug/1425264/.

I've marked LP#1425264 as a dup of this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1464442

Title:
  installing or upgrading libc6 in Trusty removes all content from /tmp
  directory

Status in eglibc package in Ubuntu:
  Confirmed

Bug description:
  We are seeing an issue with installation of dkms package during a
  curtin installation which ends up with /tmp directory being wiped
  clean. This is very bad for curtin as it saves critical installation
  files in /tmp.

  It turns out that it's the of upgrading libc6, which is triggered as a
  result of installing dependencies, that removes content of /tmp. For
  example, installation of gcc results in the same result since it ends
  up with libc6 being upgraded. The only way that this won't be
  recreated is if the latest libc6 is already installed.

  This problem does not exist in precise. It can also be recreated by
  installing the .deb file for any version in trusty including 2.17.

  
  ubuntu@host:~$ ls /tmp
  tmpHHbRkP
  ubuntu@sirrush:~$ sudo apt-get install libc6
  sudo: unable to resolve host sirrush
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following extra packages will be installed:
    libc-dev-bin libc6-dev
  Suggested packages:
    glibc-doc
  Recommended packages:
    manpages-dev
  The following packages will be upgraded:
    libc-dev-bin libc6 libc6-dev
  3 upgraded, 0 newly installed, 0 to remove and 148 not upgraded.
  Need to get 6,714 kB of archives.
  After this operation, 6,144 B disk space will be freed.
  Do you want to continue? [Y/n] y
  Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc6-dev amd64 
2.19-0ubuntu6.6 [1,910 kB]
  Get:2 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc-dev-bin 
amd64 2.19-0ubuntu6.6 [68.9 kB]
  Get:3 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc6 amd64 
2.19-0ubuntu6.6 [4,735 kB]
  Fetched 6,714 kB in 0s (18.5 MB/s)
  Preconfiguring packages ...
  (Reading database ... 57798 files and directories currently installed.)
  Preparing to unpack .../libc6-dev_2.19-0ubuntu6.6_amd64.deb ...
  Unpacking libc6-dev:amd64 (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ...
  Preparing to unpack .../libc-dev-bin_2.19-0ubuntu6.6_amd64.deb ...
  Unpacking libc-dev-bin (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ...
  Preparing to unpack .../libc6_2.19-0ubuntu6.6_amd64.deb ...
  Unpacking libc6:amd64 (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ...
  Processing triggers for man-db (2.6.7.1-1) ...
  Setting up libc6:amd64 (2.19-0ubuntu6.6) ...
  Setting up libc-dev-bin (2.19-0ubuntu6.6) ...
  Setting up libc6-dev:amd64 (2.19-0ubuntu6.6) ...
  Processing triggers for libc-bin (2.19-0ubuntu6.3) ...
  ubuntu@host:~$ ls /tmp
  ubuntu@host:~$
  

  This is very recreatable.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp