Re: [Touch-packages] [Bug 1673350] [NEW] dm-queue-length module is not included in installer/initramfs
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
; ... > 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
** 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
** 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)
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=4163mtu 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
** 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
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
** 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
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