Re: [Touch-packages] [Bug 1673350] [NEW] dm-queue-length module is not included in installer/initramfs

2017-03-16 Thread Michael Hohnbaum
e during installation (stage 1)
>
> == Comment: #1 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:12:30 ==
> Patch for 16.04 multipath-tools
>
> == Comment: #2 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:12:56 ==
> Patch for 16.04 linux
>
> == Comment: #3 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:13:18 ==
> Patch for 17.04 multipath-tools
>
> == Comment: #4 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:16:27 ==
> Patch verification on 16.04:
> ---
>
> multipath-tools source package:
>
> # sed -n '/vendor.*XtremIO/,/selector/ p' libmultipath/hwtable.c 
> .vendor= "XtremIO",
> .product   = "XtremApp",
> .features  = DEFAULT_FEATURES,
> .hwhandler = DEFAULT_HWHANDLER,
> .selector  = "queue-length 0",
>
> - initramfs:
>   -
>
> Before (module not included in initramfs):
>
> # dpkg -s multipath-tools-boot | grep ^Version:
> Version: 0.5.0+git1.656f8865-5ubuntu2.4
>
> # lsinitramfs /boot/initrd.img | grep dm-queue-length
> #
>
>
> After (module is included in initramfs):
>
> # dpkg -i multipath-tools*.deb kpartx*.deb
>
> # dpkg -s multipath-tools-boot | grep ^Version:
> Version: 0.5.0+git1.656f8865-5ubuntu2.4dmqueuelength1
>
> # lsinitramfs /boot/initrd.img | grep dm-queue-length
> lib/modules/4.4.0-66-generic/kernel/drivers/md/dm-queue-length.ko
>
>
> - kernel udeb:
>   ---
>
> # dpkg-deb -c 
> multipath-modules-4.4.0-66-generic-di_4.4.0-66.87dmqueuelength1_ppc64el.udeb 
> | grep dm-queue-length
> -rw-r--r-- root/root 12174 2017-03-14 17:17 
> ./lib/modules/4.4.0-66-generic/kernel/drivers/md/dm-queue-length.ko
>
>
> Patch verification on 17.04:
> ---
>
> Before:
>
> # dpkg -s multipath-tools-boot | grep ^Version: 
> Version: 0.6.4-3ubuntu1
>
> # lsinitramfs /boot/initrd.img | grep dm-queue-length
> # 
>
> After:
>
> # dpkg -i multipath-tools*.deb kpartx*.deb
>
> # dpkg -s multipath-tools-boot | grep ^Version: 
> Version: 0.6.4-3ubuntu1dmqueuelength1
>
> # lsinitramfs /boot/initrd.img | grep dm-queue-length
> lib/modules/4.10.0-11-generic/kernel/drivers/md/dm-queue-length.ko
>
>
> - kernel udeb:
>   ---
>
> # dpkg-deb -c 
> multipath-modules-4.10.0-11-generic-di_4.10.0-11.13dmqueuelength1_ppc64el.udeb
>  | grep dm-queue-length
> -rw-r--r-- root/root 13128 2017-03-15 11:14 
> ./lib/modules/4.10.0-11-generic/kernel/drivers/md/dm-queue-length.ko
>
> == Comment: #5 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:20:14 ==
> Patch for 17.04 linux
>
> == Comment: #9 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:24:40 ==
> @taco-screen-team
>
> Please assign this bug to @cyphermox for the multipath-tools components, at 
> least, as a suggestion.
> He's handled most of the multipath-tools related bugs/patches we've been 
> contributing with.
>
> Thank you.
>
> == Comment: #10 - Mauricio Faria De Oliveira <mauri...@br.ibm.com> - 
> 2017-03-15 09:40:17 ==
> It's possible to reproduce this problem in a qemu-kvm guest,
> with an emulated disk: force the queue-length path selector.
>
> # name=mfo-1704
> # disk=/var/lib/libvirt/images/$name.qcow2
> # iso=/var/lib/libvirt/images/zesty-server-ppc64el.iso.2017-03-14
>
> # qemu-img create -f qcow2 $disk 128g
>
> # virt-install \
>   --name $name \
>   --cdrom $iso \
>   --vcpus 8,sockets=1,cores=1,threads=8 \
>   --memory 8192 \
>   --controller type=scsi,model=virtio-scsi \
>   --disk format=qcow2,path=$disk \
>   --disk device=cdrom,readonly=true,path=$iso \
>   --network bridge=virbr0,model=virtio
>
>
> Before the disk-detection stage (e.g., set-up users and passwords),
> Go Back, Execute a shell, and set up multipath.conf, and resume install:
>
> ~ # cat </etc/multipath.conf
> defaults {
>   path_selector "queue-length 0"
>   user_friendly_names yes
>   find_multipaths no
> }
> EOF
>
> ~ # exit
>
> ** Affects: ubuntu
>  Importance: Undecided
>  Assignee: Taco Screen team (taco-screen-team)
>  Status: New
>
>
> ** Tags: architecture-ppc64le bugnameltc-152598 severity-critical 
> targetmilestone-inin16043

-- 
Michael Hohnbaum
OIL Program Manager
Power (ppc64el) Development Project Manager
Canonical, Ltd.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, w

Re: [Touch-packages] [Bug 1629226] [NEW] systemd's service killed by cgroup controller pids

2017-02-27 Thread Michael Hohnbaum
; ...
> 19236 clone(child_stack=0, 
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
> child_tidptr=0x3fff96c25aa0) = -1 EAGAIN (Resource temporarily unavailable)
> 19236 write(2, "/usr/local/bin/real_forkit.sh: f"..., 70) = 70
> 19236 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> 19236 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> 19236 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> 19236 exit_group(254)   = ?
> 19236 +++ exited with 254 +++
>
> The problem here is that the replication script is not *handling* the
> error.  It is not even looking at the return code of the function it is
> trying to fork.  It is very possible that the shell itself triggered its
> own protection mechanism when faced with a script that appeared to be
> running away (the above exit was not after the first clone failure, but
> after several calls to clone had failed).
>
> Personally, if I were the admin of this system, this is exactly what I
> would want to happen to a run away process (smack it down quickly).
>
> == Comment: #10 - Ping Tian Han <pt...@cn.ibm.com> - 2016-03-29 21:17:16 ==
> (In reply to comment #9)
>> The process in question wasn't killed. It did its own exit:
>>
>> ...
>> 19236 clone(child_stack=0,
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> child_tidptr=0x3fff96c25aa0) = -1 EAGAIN (Resource temporarily unavailable)
>> 19236 write(2, "/usr/local/bin/real_forkit.sh: f"..., 70) = 70
>> 19236 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>> 19236 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
>> 19236 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>> 19236 exit_group(254)   = ?
>> 19236 +++ exited with 254 +++
>>
>> The problem here is that the replication script is not *handling* the error.
>> It is not even looking at the return code of the function it is trying to
>> fork.  It is very possible that the shell itself triggered its own
>> protection mechanism when faced with a script that appeared to be  running
>> away (the above exit was not after the first clone failure, but after
>> several calls to clone had failed).
>>
> Thanks, Kevin. Looks like this is a problem of bash? I think there isn't
> any reason casuing a shell process as parents to quit just because it
> cannot fork more child processes...
>
>> Personally, if I were the admin of this system, this is exactly what I would
>> want to happen to a run away process (smack it down quickly).
> ** Affects: ubuntu
>  Importance: Undecided
>  Assignee: Taco Screen team (taco-screen-team)
>  Status: New
>
>
> ** Tags: architecture-ppc64le bugnameltc-139320 severity-medium 
> targetmilestone-inin---

-- 
Michael Hohnbaum
OIL Program Manager
Power (ppc64el) Development Project Manager
Canonical, Ltd.

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

Title:
  systemd's service killed by cgroup controller pids

Status in bash package in Ubuntu:
  New

Bug description:
  Problem Description
  ===
  I write a simple systemd service which will fork child processes fiercely. 
But quickly the service failed:

  % sudo systemctl status reproducer.service
  ? reproducer.service - Reproducer of systemd services killed by ips
 Loaded: loaded (/etc/systemd/system/reproducer.service; disabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Fri 2016-03-18 06:58:37 CDT; 2min 
43s ago
Process: 5103 ExecStart=/home/hpt/reproducer/reproducer.sh (code=exited, 
status=0/SUCCESS)
   Main PID: 5105 (code=exited, status=254)

  Mar 18 06:58:36 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:36 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 systemd[1]: reproducer.service: Main process exited, 
code=exited, status=254/n/a
  Mar 18 06:58:37 pinelp3 reproducer.sh[5103]: 
/home/hpt/reproducer/reproducer.sh: fork: Resource temporarily unavailable
  Mar 18 06:58:37 pinelp3 systemd[1]: reproducer.service: Unit entered failed 
sta

[Touch-packages] [Bug 1537125] Re: ubuntu-14.04.04: fail to run systemtap test suites

2017-02-24 Thread Michael Hohnbaum
** Changed in: systemtap (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 elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1537125

Title:
  ubuntu-14.04.04: fail to run systemtap test suites

Status in elfutils package in Ubuntu:
  Fix Released
Status in systemtap package in Ubuntu:
  Confirmed

Bug description:
  ---Problem Description---
  ubuntu-14.04.04: fail to run systemtap test suites
   
  ---uname output---
  Linux u140404 4.2.0-21-generic #25~14.04.1-Ubuntu SMP Thu Dec 3 13:55:42 UTC 
2015 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = power8 

  As per launchpad feature systemtap now supported and enabled on 14.04.04
  - https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1511347

  Here are the steps followed to test systemtap -
  1.  Get 14.04.04 guest VM

  2.  apt-get update; apt-get install dpkg-dev; apt-get build-dep
  systemtap

  3. setup repo
  codename=$(lsb_release -c | awk  '{print $2}')
  sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
  deb http://ddebs.ubuntu.com/ ${codename}  main restricted universe 
multiverse
  deb http://ddebs.ubuntu.com/ ${codename}-security main restricted universe 
multiverse
  deb http://ddebs.ubuntu.com/ ${codename}-updates  main restricted universe 
multiverse
  deb http://ddebs.ubuntu.com/ ${codename}-proposed main restricted universe 
multiverse
  EOF

  4. apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01
  5E0577F2

  5. apt-get update

  6.  devel packages
  apt-get install linux-image-`uname -r`-dbgsym 
  apt-get install linux-headers-4.2.0-24-generic

  7.  Install required dependencies 
- dejagnu, elfutils-*

  8. apt-get source systemtap

  9.  appy systemtap fixes 
  see BZ - https://bugzilla.linux.ibm.com/show_bug.cgi?id=131220

  root@u140404:~/patch# ll
  total 32
  drwxr-xr-x 2 root root 4096 Jan  7 03:36 ./
  drwx-- 8 root root 4096 Jan  7 03:55 ../
  -rw-r--r-- 1 root root 6763 Jan  7 03:36 systemtap-1
  -rw-r--r-- 1 root root 3094 Jan  7 03:35 systemtap-1511347.diff
  -rw-r--r-- 1 root root 3472 Jan  7 03:36 systemtap-2
  -rw-r--r-- 1 root root 5864 Jan  7 03:36 systemtap-3

  cd /root/systemtap-2.3
  apply above patch in below order
  patch -p1 < /root/patch/systemtap-1511347.diff
  patch -p1 < /root/patch/systemtap-1
  patch -p1 < /root/patch/systemtap-2
  patch -p1 < /root/patch/systemtap-3

  10. ./configure; make -j10; make install

  11.  make check  ---> failed
  root@u140404:~/systemtap-2.3# make check
  /bin/bash ./git_version.sh -k -s . -o git_version.h
  make  check-recursive
  make[1]: Entering directory `/root/systemtap-2.3'
  Making check in .
  make[2]: Entering directory `/root/systemtap-2.3'
CXX  stap-session.o
CXXLDstap
  make  check-local
  make[3]: Entering directory `/root/systemtap-2.3'
  SRCDIR=`cd .; pwd`; \
  PWD=`pwd`; \
make -C testsuite check SYSTEMTAP_RUNTIME=$SRCDIR/runtime 
SYSTEMTAP_TAPSET=$SRCDIR/tapset 
LD_LIBRARY_PATH=$LD_LIBRARY_PATH${LD_LIBRARY_PATH:+:}$PWD/lib-elfutils:$PWD/lib-elfutils/systemtap
 SYSTEMTAP_PATH=$PWD SYSTEMTAP_INCLUDES=$PWD/includes RUNTESTFLAGS="" 
PKGLIBDIR="/usr/local/libexec/systemtap";
  make[4]: Entering directory `/root/systemtap-2.3/testsuite'
  Run "make check" or "make installcheck".
  make  check-DEJAGNU check-local
  make[5]: Entering directory `/root/systemtap-2.3/testsuite'
  srcdir='.'; export srcdir; \
EXPECT=expect; export EXPECT; \
if /bin/bash -c ""env XDG_DATA_DIRS= SYSTEMTAP_SYNC=1 LANG=C 
SYSTEMTAP_TESTREMOTES= SYSTEMTAP_TESTAPPS= 
SYSTEMTAP_RUNTIME=/root/systemtap-2.3/runtime 
SYSTEMTAP_TAPSET=/root/systemtap-2.3/tapset 
LD_LIBRARY_PATH=/root/systemtap-2.3/lib-elfutils:/root/systemtap-2.3/lib-elfutils/systemtap
 CRASH_LIBDIR=/usr/local/lib/systemtap PATH=/root/systemtap-2.3:$PATH 
SYSTEMTAP_PATH=/root/systemtap-2.3 
SYSTEMTAP_INCLUDES=/root/systemtap-2.3/includes  
PKGLIBDIR=/usr/local/libexec/systemtap ./execrc runtest" --version" > /dev/null 
2>&1; then \
  exit_status=0; l='systemtap'; for tool in $l; do \
if "env XDG_DATA_DIRS= SYSTEMTAP_SYNC=1 LANG=C 
SYSTEMTAP_TESTREMOTES= SYSTEMTAP_TESTAPPS= 
SYSTEMTAP_RUNTIME=/root/systemtap-2.3/runtime 
SYSTEMTAP_TAPSET=/root/systemtap-2.3/tapset 
LD_LIBRARY_PATH=/root/systemtap-2.3/lib-elfutils:/root/systemtap-2.3/lib-elfutils/systemtap
 CRASH_LIBDIR=/usr/local/lib/systemtap PATH=/root/systemtap-2.3:$PATH 
SYSTEMTAP_PATH=/root/systemtap-2.3 
SYSTEMTAP_INCLUDES=/root/systemtap-2.3/includes  
PKGLIBDIR=/usr/local/libexec/systemtap ./execrc runtest"  --tool $tool 
--tool_opts \'\' --srcdir $srcdir ; \
then :; else exit_status=1; fi; \
  done; \
else echo "WARNING: could not find '"env XDG_DATA_DIRS= 
SYSTEMTAP_SYNC=1 LANG=C SYSTEMTAP_TESTREMOTES= SYSTEMTAP_TESTAPPS= 

[Touch-packages] [Bug 1389164] Re: Ubuntu 14.10 ppc64le not automatically mounting NFS mounts in /etc/fstab

2017-02-06 Thread Michael Hohnbaum
** Changed in: mountall (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 mountall in Ubuntu.
https://bugs.launchpad.net/bugs/1389164

Title:
  Ubuntu 14.10 ppc64le not automatically mounting NFS mounts in
  /etc/fstab

Status in mountall package in Ubuntu:
  Incomplete

Bug description:
  Problem Description
  
  It seems the remote mounts in my /etc/fstab file are not being automatically 
mounted at bootup with ppc64le Ubuntu 14.10. This leads to some of my upstart 
scripts not running because they require certain mounts being available. I can 
give access to the machine via SSH key or password. Using mount -a or any other 
mount command works just fine after bootup. I don't personally notice a problem 
in logs with mounts.

  The machine is a VM hosted on a Power8 PowerKVM system running:
  # uname -a
  Linux kvm10d724t.rtp.raleigh.ibm.com 3.10.23-1700.pkvm2_1.2.ppc64 #1 SMP Mon 
Jun 2 20:14:25 CDT 2014 ppc64 ppc64 ppc64 GNU/Linux
  # cat /etc/base-release
  IBM_PowerKVM release 2.1.0 build 18 Service (pkvm2_1)

  VM details:
  # uname -a
  Linux cit607 3.16.0-20-generic #27-Ubuntu SMP Wed Oct 1 17:24:38 UTC 2014 
ppc64le ppc64le ppc64le GNU/Linux
  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=14.10
  DISTRIB_CODENAME=utopic
  DISTRIB_DESCRIPTION="Ubuntu Utopic Unicorn (development branch)"

  If I recall correctly, we installed the 141002 daily build of Utopic
  Unicorn (14.10).

  I have implemented a workaround for now. I updated /etc/fstab to use
  IP addresses instead of names, put "mount -a" as the first non-
  commented line in /etc/init.d/mountnfs.sh and updated the crontab to
  run the jobs I had in the upstart configs. This works until the
  problem is fixed.

  ---uname output---
  Linux cit607 3.16.0-20-generic #27-Ubuntu SMP Wed Oct 1 17:24:38 UTC 2014 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le 
   
  Steps to Reproduce
  =
   Without the workaround implemented and NFS mounts in your /etc/fstab, boot 
up the machine. It should be evident the mount points aren't there with df -h.

  == Comment: #3 - Breno Henrique Leitao  -  ==
  I was able to reproduce this problem.
  NFS is not mounted automatically, but it is when you run 'mount -a'. 
  I also toggled ASYNCMOUNTNFS in /etc/defaults/rcS and no luck.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1389164/+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] Fwd: [Bug 1660762] [NEW] [Regression] Interface configuration not restored after driver unbind/bind (generic)

2017-01-31 Thread Michael Hohnbaum
Leann,

Could you please have someone from the Kernel team look at this reported
regression.

Thanks.

  Michael


 Forwarded Message 
Subject:[Bug 1660762] [NEW] [Regression] Interface configuration not
restored after driver unbind/bind (generic)
Date:   Tue, 31 Jan 2017 19:49:16 -
From:   Launchpad Bug Tracker <1660...@bugs.launchpad.net>
Reply-To:   Bug 1660762 <1660...@bugs.launchpad.net>
To: michael.hohnb...@canonical.com


bugproxy (bugproxy) has assigned this bug to you for Ubuntu:

---Problem Description---
Interface configuration not restored after driver unbind/bind
 

root@ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4163  mtu 1500
inet 10.10.10.11  netmask 255.255.255.0  broadcast 10.10.10.255
inet6 fe80::290:faff:fe7a:5840  prefixlen 64  scopeid 0x20
ether 00:90:fa:7a:58:40  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 13  bytes 1046 (1.0 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@ltciofvtr-s824-lp8:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ibmveth2
iface ibmveth2 inet static
address 9.47.68.120
netmask 255.255.240.0
network 9.47.64.0
broadcast 9.47.79.255
gateway 9.47.79.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 9.12.18.2
dns-search pok.stglabs.ibm.com

auto enP28p96s0f0
iface enP28p96s0f0 inet static
   address 10.10.10.11
   netmask 255.255.255.0

root@ltciofvtr-s824-lp8:~# ethtool -i enP28p96s0f0
driver: be2net
version: 11.1.0.0
firmware-version: 10.2.252.1913
expansion-rom-version: 
bus-info: 001c:60:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: yes

root@ltciofvtr-s824-lp8:~# echo -n 001c:60:00.0 >
/sys/bus/pci/drivers/be2net/unbind

root@ltciofvtr-s824-lp8:~# ls /sys/bus/pci/drivers/be2net 
001c:60:00.1  001c:60:00.2  001c:60:00.3  bind  module  new_id  remove_id  
uevent  unbind

root@ltciofvtr-s824-lp8:~# echo -n 001c:60:00.0 >
/sys/bus/pci/drivers/be2net/bind

root@ltciofvtr-s824-lp8:~# ls /sys/bus/pci/drivers/be2net
001c:60:00.0  001c:60:00.1  001c:60:00.2  001c:60:00.3  bind  module  new_id  
remove_id  uevent  unbind

root@ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4098  mtu 1500
ether 00:90:fa:7a:58:40  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@ltciofvtr-s824-lp8:~# ifup enP28p96s0f0
ifup: interface enP28p96s0f0 already configured

root@ltciofvtr-s824-lp8:~# ifdown enP28p96s0f0
RTNETLINK answers: Cannot assign requested address

root@ltciofvtr-s824-lp8:~# ifup enP28p96s0f0

root@ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4163  mtu 1500
inet 10.10.10.11  netmask 255.255.255.0  broadcast 10.10.10.255
inet6 fe80::290:faff:fe7a:5840  prefixlen 64  scopeid 0x20
ether 00:90:fa:7a:58:40  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 16  bytes 1344 (1.3 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 
---uname output---
Linux ltciofvtr-s824-lp8 4.9.0-12-generic #13-Ubuntu SMP Tue Jan 10 12:52:39 
UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
 
Machine Type = IBM,8286-42A LPAR 
  
---Steps to Reproduce---
 # echo -n 001c:60:00.0 > /sys/bus/pci/drivers/be2net/unbind

# echo -n 001c:60:00.0 > /sys/bus/pci/drivers/be2net/bind
 
== Comment - Vaishnavi Bhat
Hi,

To bind a device to a driver, the device must first not be controlled by any 
other driver. Can you check for 'driver' in the below before you bind ?
 $ tree /sys//bus/pci/devices/001c:60:00.0 

Thank you.

== Comment - Murilo Fossa Vicentini
Just adding some information, this is not a driver specific issue, this was 
also seen with tg3 and i40e adapters . This behavior is a regression when 
compared to Ubuntu 16.04 where the interfaces where properly reconfigured upon 
bind with the information set in /etc/network/interfaces

** Affects: ubuntu
 Importance: Undecided
 Assignee: Taco Screen team (taco-screen-team)
 Status: New


** Tags: architecture-ppc64le bugnameltc-151103 severity-high 
targetmilestone-inin1704
-- 
[Regression] Interface configuration not restored after driver 

[Touch-packages] [Bug 1368302] Re: eglibc source tests are failing in Ubuntu 14.10 guest

2016-03-03 Thread Michael Hohnbaum
** Changed in: eglibc (Ubuntu)
   Status: New => Invalid

-- 
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/1368302

Title:
  eglibc source tests are failing in Ubuntu 14.10 guest

Status in eglibc package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---
  eglibc source tests are failing in Ubuntu 14.10 guest

  ---uname output---
  Linux ubuntu 3.16.0-12-generic #18-Ubuntu SMP Mon Sep 1 13:03:43 UTC 2014 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = P8 

  ---Steps to Reproduce---
  Install a P8 system with Power KVM and then install Ubuntu 14.10 guest.
  Then try to build and execute the eglibc source test suites as below.

  root@ubuntu:~# apt-get source eglibc
  root@ubuntu:~# cd eglibc-2.19/
  root@ubuntu:~/eglibc-2.19# dpkg-buildpackage -b 2>&1 | tee eglibclog

  #
  # Testsuite failures, someone should be working towards
  # fixing these! They are listed here for the purpose of
  # regression testing during builds.
  # Format: , Error  [(ignored)]
  #
  annexc.out, Error 1 (ignored)
  run-conformtest.out, Error 1 (ignored)
  tst-cancelx17.out, Error 1
  tst-cpuclock2.out, Error 1
  ***
  Encountered regressions that don't match expected failures 
(debian/testsuite-checking/expected-results-powerpc64le-linux-gnu-libc):
  tst-cancelx17.out, Error 1
  TEST tst-cancelx17.out:
  going to cancel tf in-time
  going to cancel tf2 in-time
  in-time cancellation succeeded
  aio_cancel failed
  going to cancel tf early
  going to cancel tf2 early
  early cancellation succeeded
  Encountered progressions that don't match expected failures:
  check-localplt.out, Error 1
  tst-cputimer1.out, Error 1
  tst-mqueue5.out, Error 1
  tst-waitid.out, Error 1
  debian/rules.d/build.mk:123: recipe for target 
'/root/eglibc-2.19/stamp-dir/check_libc' failed
  make: *** [/root/eglibc-2.19/stamp-dir/check_libc] Error 1
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

tried the same steps in the provided  VM (192.168.122.70) and dpkg-
  buildpackage -b completed fine.

  ouch /root/eglibc-2.19/stamp-dir/binaryinst_libnss-files-udeb
   dpkg-genchanges -b >../eglibc_2.19-0ubuntu6_ppc64el.changes
  dpkg-genchanges: warning: package locales in control file but not in files 
list
  dpkg-genchanges: warning: package locales-all in control file but not in 
files list
  dpkg-genchanges: binary-only upload (no source code included)
   dpkg-source --after-build eglibc-2.19
  dpkg-source: info: using options from eglibc-2.19/debian/source/options: 
--compression=xz
  dpkg-buildpackage: binary-only upload (no source included)
  root@ubuntu:~/eglibc-2.19#

  Hi Rajalakshmi,

  If you grep for "Testsuite failures" in the eglibclog file, you get
  the below failures listed.

  
  #
  # Testsuite failures, someone should be working towards
  # fixing these! They are listed here for the purpose of
  # regression testing during builds.
  # Format: , Error  [(ignored)]
  #
  annexc.out, Error 1 (ignored)
  run-conformtest.out, Error 1 (ignored)
  tst-cpuclock2.out, Error 1
  ***
  Passed regression testing. No new failures, no changed error values.
  TEST annexc.out:
  The following identifiers will be ignored since the compiler defines them
  by default:
  pixel
  bool
  vector
  unix
  linux
  Tested files:
  === aio.h ===
  *  invalid macro `SIGEV_THREAD_ID'
  *  invalid macro `sigev_notify_function'
  *  invalid macro `sigev_notify_attributes'
  ** macro `FD_CLOEXEC' not defined
  ** macro `F_DUPFD' not defined
  ** macro `F_GETFD' not defined
  ** macro `F_GETFL' not defined
  ** macro `F_GETLK' not defined
  ** macro `F_RDLCK' not defined
  ** macro `F_SETFD' not defined
  ** macro `F_SETFL' not defined
  ** macro `F_SETLK' not defined
  ** macro `F_SETLKW' not defined
  ** macro `F_UNLCK' not defined
  ** macro `F_WRLCK' not defined
  ** macro `O_ACCMODE' not defined
  ** macro `O_APPEND' not defined
  ** macro `O_CREAT' not defined
  ** macro `O_DSYNC' not defined
  ** macro `O_EXCL' not defined
  ** macro `O_NOCTTY' not defined
  ** macro `O_NONBLOCK' not defined
  ** macro `O_RDONLY' not defined
  ** macro `O_RDWR' not defined
  ** macro `O_RSYNC' not defined
  ** macro `O_SYNC' not defined
  ** macro `O_TRUNC' not defined
  ** macro `O_WRONLY' not defined
  ** macro `SA_NOCLDSTOP' not defined
  ** macro `SA_SIGINFO' not defined
  ** macro `SIGABRT' not defined
  ** macro `SIGALRM' not defined
  ** macro `SIGBUS' not defined
  ** macro `SIGCHLD' not defined
  ** macro `SIGCONT' not defined
  ** macro `SIGEV_SIGNAL' not defined
  ** macro `SIGFPE' not defined
  ** macro `SIGHUP' not defined
  ** macro `SIGILL' not defined
  ** macro `SIGINT' not defined
  ** macro `SIGKILL' not defined
  ** macro `SIGPIPE' not defined
  ** macro `SIGQUIT' not defined
  ** macro `SIGRTMAX' not defined
  ** macro `SIGSEGV' not defined
  ** macro 

[Touch-packages] [Bug 1478087] Re: Add libaudit support

2016-01-25 Thread Michael Hohnbaum
Mathieu, any outlook for this SRU?

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

Title:
  Add libaudit support

Status in Light Display Manager:
  Fix Released
Status in Light Display Manager 1.10 series:
  Fix Committed
Status in Light Display Manager 1.14 series:
  Fix Released
Status in Light Display Manager 1.16 series:
  Fix Released
Status in Light Display Manager 1.2 series:
  Won't Fix
Status in audit package in Ubuntu:
  Invalid
Status in lightdm package in Ubuntu:
  Fix Released
Status in openssh package in Ubuntu:
  Fix Released
Status in shadow package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  Triaged
Status in openssh source package in Trusty:
  Triaged
Status in shadow source package in Trusty:
  Triaged
Status in lightdm source package in Vivid:
  Triaged
Status in openssh source package in Vivid:
  Triaged
Status in shadow source package in Vivid:
  Triaged
Status in lightdm source package in Wily:
  Fix Released
Status in openssh source package in Wily:
  Fix Released
Status in shadow source package in Wily:
  Fix Released

Bug description:
  [Impact]
  Auditing support is a commonly used feature in large enterprises, and allows 
better tracking of actions happening on secured systems, especially when it 
comes to accounting for login events.

  Such systems fail to correctly list login events in aureport due to
  some software not integrating libaudit.

  [Test Case]
  1) Install auditd
  2) Login to the system multiple times (or allow for others to connect to the 
system)
  3) Run aureport -l

  System should list login information.

  [Regression Potential]
  There is minimal risk for issues since libaudit support only allows for 
generating extra logging saved on the local system. A possible side-effect of 
this may be that systems on which auditing is enabled and where there are many 
users of the affected software (see bug tasks), such as many logins over SSH, 
there may be an increased demand on disk space necessary for the auditing data.

  ---

  -- Problem Description --
  We installed ubuntu 14.04.3 on lakelp1 and installed package auditd. We tried 
to
  ssh to lakelp1 several times and found that "aureport -l" couldn't print out 
the login
  info.

  root@lakelp1:~# /etc/init.d/auditd status
   * auditd is running.

  root@lakelp1:~# auditctl -e 1
  AUDIT_STATUS: enabled=1 flag=1 pid=38784 rate_limit=0 backlog_limit=320 
lost=12 backlog=1

  root@lakelp1:~# grep -i login /var/log/audit/audit.log
  type=LOGIN msg=audit(1437641256.987:67): pid=11752 uid=0 old-auid=4294967295 
auid=0 old-ses=4294967295 ses=4 res=1
  type=LOGIN msg=audit(1437642646.478:85): pid=44269 uid=0 old-auid=4294967295 
auid=0 old-ses=4294967295 ses=5 res=1
  type=LOGIN msg=audit(1437642700.295:90): pid=21504 uid=0 old-auid=4294967295 
auid=0 old-ses=4294967295 ses=6 res=1
  type=LOGIN msg=audit(1437642765.339:104): pid=16628 uid=0 old-auid=4294967295 
auid=0 old-ses=4294967295 ses=7 res=1
  type=LOGIN msg=audit(1437644638.593:130): pid=3 uid=0 old-auid=4294967295 
auid=0 old-ses=4294967295 ses=8 res=1

  root@lakelp1:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  

  This looks like a bug in aureport or libaudit. In addition to giving
  admins falsely empty record selections, this would prevent successful
  completion of a Common Criteria certification.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1478087/+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 1483586] Re: On demand cpufreq govneror causes large amounts of jitter

2015-11-02 Thread Michael Hohnbaum
** Tags added: targetmilestone-inin1404

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

Title:
  On demand cpufreq govneror causes large amounts of jitter

Status in sysvinit package in Ubuntu:
  Fix Released
Status in sysvinit source package in Trusty:
  Triaged
Status in sysvinit source package in Vivid:
  New

Bug description:
  == Comment: #0 - Anton Blanchard  - 2015-07-16 22:22:09 ==
  We are seeing large amounts of jitter caused by od_dbs_timer(). We should 
slow down the rate of updates and or turn this into a timer. Having a workqueue 
execute so often is very noticeable.

  # echo 1 >
  /sys/kernel/debug/tracing/events/workqueue/workqueue_execute_start/enable

  (wait a while)

  # cat /sys/kernel/debug/trace

 <...>-67605 [040]  849622.393576: workqueue_execute_start: 
work struct c007fba1ba20: function od_dbs_timer
 <...>-67605 [040]  849622.403574: workqueue_execute_start: 
work struct c007fba1ba20: function od_dbs_timer
 <...>-116685 [048]  849622.403575: workqueue_execute_start: 
work struct c007fbc1ba20: function od_dbs_timer
 <...>-116685 [048]  849622.413574: workqueue_execute_start: 
work struct c007fbc1ba20: function od_dbs_timer
 <...>-67605 [040]  849622.413575: workqueue_execute_start: 
work struct c007fba1ba20: function od_dbs_timer
 <...>-67605 [040]  849622.423575: workqueue_execute_start: 
work struct c007fba1ba20: function od_dbs_timer
 <...>-116685 [048]  849622.433574: workqueue_execute_start: 
work struct c007fbc1ba20: function od_dbs_timer
 <...>-67605 [040]  849622.433574: workqueue_execute_start: 
work struct c007fba1ba20: function od_dbs_timer
 <...>-116685 [048]  849622.443573: workqueue_execute_start: 
work struct c007fbc1ba20: function od_dbs_timer

  == Comment: #1 - Shilpasri G. Bhat  - 2015-07-22 
19:42:38 ==
  Hi Anton,

  We can set the governor's tunable 'sampling_down_factor' to decrease
  the rate of updates. When this tunable is set to a value greater than
  1, the sampling period of the governor is increased during the peak
  load to sampling_period times sampling_down_factor. This will reduce
  the jitter caused by od_dbs_timer() when the cpu is busy.

  I am currently running benchmarks to find out the optimal value for
  this tunable and will post them soon.

  Thanks and Regards,
  Shilpa

  == Comment: #2 - Anton Blanchard  - 2015-07-31 03:44:49 ==
  FYI We are also seeing high levels of CPU consumed by this on a LAMP workload:

   2.54%  kworker/0:0  [kernel.kallsyms] [k] osq_lock
  |   
  ---osq_lock
 |   
 |--99.83%-- mutex_optimistic_spin
 |  __mutex_lock_slowpath
 |  mutex_lock
 |  |  
 |  |--80.08%-- od_dbs_timer

  2.5% of total CPU time spent in the od_dbs_timer mutex.

  == Comment: #3 - Anton Blanchard  - 2015-07-31 06:00:45 ==
  Hitting this on a customer setup, raising priority

  == Comment: #4 - Shilpasri G. Bhat  - 2015-08-03 
06:47:40 ==
  I used `perf top` and `perf record` to observe the overhead caused by 
'osq_lock'.
  Both with ebizzy and SPECPower's ssjb workload I am able to see an overhead 
of 0.03% caused by 'osq_lock' with default governor settings. 
  With sampling_down_factor=100, (1second) I am able to see 0.00% of overhead 
by 'osq_lock'.

  So this might not be a good data point to showcase, but by reducing
  the  od_dbs_timer interrupts we are guaranteed to decrease the
  overhead caused by 'osq_lock'.

  == Comment: #5 - VAIDYANATHAN SRINIVASAN  - 2015-08-03 
09:09:09 ==
  Hi Anton,

  Thanks for opening the bz to track and fix this issue.  Shilpa is
  trying different workarounds.  Here is our plan:

  (1) Use sampling_down_factor and other tunables in current Ubuntu
  releases to workaround the issue or minimise the impact.

  (2) Redesign cpufreq subsystem on powerpc similar to intel pstate
  driver so that we can program timers and cancel them dynamically based
  on different utilization points.  Target Ubuntu 16.04 and then
  backport to 14.04.x and other distros.

  (3) Enhance design for (2) buy estimating core level utilization
  without running timers in each thread and then decide the target
  PState

  (4) Explore hardware assist so that we can avoid per-core estimation
  in software but still be able to set per-core PState. We need to take
  an interrupt or work-queue only to change PState and not really for
  estimation of load.  Hence steady state load will experience zero
  jitter 

[Touch-packages] [Bug 1400420] Re: [Ubuntu 15.04] Mesa/gallium: Fix Altivec pack intrinsics for little endian

2015-01-06 Thread Michael Hohnbaum
If the patch is already included, is anything else needed from Canonical
for this?

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

Title:
  [Ubuntu 15.04] Mesa/gallium:  Fix Altivec pack intrinsics for little
  endian

Status in mesa package in Ubuntu:
  In Progress

Bug description:
  Please ensure the following patch is incorporated into the mesa
  package for correct behavior on ppc64el:

  http://lists.freedesktop.org/archives/mesa-dev/2014-August/064711.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1400420/+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