[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0
** Changed in: linux-signed (Ubuntu Groovy) Assignee: Colin Ian King (colin-king) => (unassigned) -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in bcache-tools package in Ubuntu: Triaged Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in bcache-tools source package in Bionic: New Status in linux source package in Bionic: New Status in linux-signed source package in Bionic: New Status in systemd source package in Bionic: New Status in bcache-tools source package in Focal: Confirmed Status in linux source package in Focal: Invalid Status in linux-signed source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in bcache-tools source package in Groovy: Triaged Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: Confirmed Status in systemd source package in Groovy: Fix Released Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+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 1992979] [NEW] kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
Public bug reported: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang ** Affects: systemd (Ubuntu) Importance: Critical Status: New ** Attachment added: "jpg of hang in boot" https://bugs.launchpad.net/bugs/1992979/+attachment/5624126/+files/Screenshot%20from%202022-10-14%2014-47-42.png ** Changed in: systemd (Ubuntu) Importance: Undecided => Critical -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: New Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
Getting the same issue on the kinetic server daily image during the install phase, see attached ** Attachment added: "issue during install" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+attachment/5624145/+files/Screenshot%20from%202022-10-14%2018-01-37.png -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: New Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
Using power9 arch, attached is the xml config ubuntu22.10-kinetic-ppc64le e410f72a-6555-4b47-bb18-8bb61eb52de2 http://libosinfo.org/xmlns/libvirt/domain/1.0";> http://ubuntu.com/ubuntu/22.04"/> 8388608 8388608 1 hvm POWER9 destroy restart destroy /usr/bin/qemu-system-ppc64le -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: New Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
It is normally always preferable to use the intel-pstate driver compared to pcc-cpufreq or acpi-cpufreq on modern Intel hardware. Some HP ProLiant platforms implement the PCC interface [1] which can be disabled by a BIOS setting in which case the PCC driver will not load and the acpi-cpufreq driver can be used instead. The intel-pstate driver is presumed to be better for Sandybridge CPUs and later. Unlike the the cpufreq drivers, it uses P-states rather than cpu frequency [2]. It also has access to CPU performance metrics so in theory it has finer control than the traditional BIOS table driven frequency scaling. So for HP Proliants that are pre-Sandybridge, pcc-cpufreq may be the best bet, providing the firmware is doing the right thing. If not, acpi- cpufreq maybe better, as long as the BIOS has the correct control data in the ACPI tables. [1] Processor Clocking Control, https://acpica.org/sites/acpica/files/Processor-Clocking-Control-v1p0.pdf [2] https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+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 1885730] Re: Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor
The choice was made from running analysis on a wide range of Intel machines, old and new. We are trying to select the optimal choice for a wide range of CPUs for a wide range of use cases. Generally speaking, the intel-pstate governor has deeper understanding of the processor features and can access CPU metrics that can guide it to making an informed choice. >From our understanding, The intel-pstate driver should be the optimal choice for Intel Sandy Bridge CPUs onwards. The intel-pstate driver supports only the performance and powersave governors. In benchmarking we didn't observe much computational difference between the too once the CPU is fully loaded. However, cranking up or cranking down the load one will discover that the performance setting is more responsive than powersave. The overall compute throughput when fully loaded is the same, it's just a case that powersave may take a little longer to crank up to the full speed. It makes sense to default to powersave for most scenarios, especially for laptop users. Pre-Intel Sandy Bridge or non-x86 CPUs will default back to the non- intel pstate governor. So, question: Which kernel(s) are you referring to? -- 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/1885730 Title: Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in linux source package in Groovy: Confirmed Status in systemd source package in Groovy: Invalid Bug description: In a recent merge from Debian we lost ondemand.service, meaning all CPUs now run in Turbo all the time when idle, which is clearly suboptimal. The discussion in bug 1806012 seems misleading, focusing on p-state vs other drivers, when in fact, the script actually set the default governor for the pstate driver on platforms that use pstate. Everything below only looks at systems that use pstate. pstate has two governors: performance and powerstate. performance runs CPU at maximum frequency constantly, and powersave can be configured using various energy profiles energy profiles: - performance - balanced performance - balanced power - power It defaults to balanced performance, I think, but I'm not sure. Whether performance governor is faster than powersave governor is not even clear. https://www.phoronix.com/scan.php?page=article&item=linux50-pstate- cpufreq&num=5 benchmarked them, but did not benchmark the individual energy profiles. For a desktop/laptop, the expected behavior is the powersave governor with balanced_performance on AC and balanced_power on battery. I don't know about servers or VMs, but the benchmark series seems to indicate it does not really matter much performance wise. I think most other distributions configure their kernels to use the powersave governor by default, whereas we configure it to use the performance governor and then switch it later in the boot to get the maximum performance during bootup. It's not clear to me that's actually useful. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+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 1885730] Re: Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor
@xnox, one can detect the machine type from the DMI data (iff it is available and reliable). e.g. on my laptop: sudo dmidecode -s "chassis-type" Notebook on my desktop server: sudo dmidecode -s "chassis-type" There are quite a few chassis-type, see https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.1.pdf - page 36, section 7.4.1, table 16 "System Enclosure or Chassic Type". *Note* some machines may have illegal data or omitted this information and it's DMI specific, so s390, arm64, ppc64el platforms most probably won't have this. So some context. This performance governor was chosen for the boot default setting because it speeds up boot. I've performed some simple boot tests on an older generation Lenovo x220 (i3-2350M), timings are below for a 5.8 kernel: Governor Kernel Userspace EndBoot PEFORFMANCE 2.15s10.37s 12.52s POWERSAVE2.87s18.49s 21.37s ONDEMAND 2.41s10.46s 12.87s So PERFORMANCE saves a few tenths of a second over ONDEMAND, hence this choice for boot. The setting thereafter is obviously more complex. I've compared the governor settings on the same laptop running idle, with 50% CPU utilization and 100% CPU utilization. I used powerstat to monitor CPU power, CPU freq and C7 (deep sleep) residency. 1. Idle. - power utilization roughly the same in power usage, but powersave clocks the CPU lowest. Note that the CPU freq is cranked up when measurements are taken, so it's hard to get a correct freq. measurement. 2. 50% CPU busy. - performance consumes most power (as expected) and the CPU is running marginally faster than on-demand. 3. 100% CPU busy. - performance and on-demand are comparable in terms of power consumption and CPU frequency. PERFORMANCE essentially runs the CPU at higher frequency all the time, whereas ONDEMAND will scale up/down depending on the utilization. I believe the default should be ONDEMAND post boot as this is the most flexible option and will provide power saving when the system is less utilized. If users want to burn power and they can opt-in to manually setting to PERFORMANCE, but I think this should be opt-in rather than the default setting for any class of machine. Finally, if we don't want the userspace changes, we could default the kernel to ONDEMAND and take a hit on slower boot performance. To clarify I see the options as: 1. Boot with PERFORMANCE and fix the userspace to set ONDEMAND in the post-boot stage 2. Failing this, don't let userspace do anything smart post-boot and default to ONDEMAND Attached are some data points I gathered with the 5.8 kernel. ** Attachment added: "LibreOffice |Calc spread sheet of boot timings and power measurements" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+attachment/5402512/+files/2020-5.8-CPU-GOVERNOR-CONFIG.ods -- 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/1885730 Title: Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in linux source package in Focal: New Status in systemd source package in Focal: Fix Released Status in linux source package in Groovy: Confirmed Status in systemd source package in Groovy: Invalid Bug description: In a recent merge from Debian we lost ondemand.service, meaning all CPUs now run in Turbo all the time when idle, which is clearly suboptimal. The discussion in bug 1806012 seems misleading, focusing on p-state vs other drivers, when in fact, the script actually set the default governor for the pstate driver on platforms that use pstate. Everything below only looks at systems that use pstate. pstate has two governors: performance and powerstate. performance runs CPU at maximum frequency constantly, and powersave can be configured using various energy profiles energy profiles: - performance - balanced performance - balanced power - power It defaults to balanced performance, I think, but I'm not sure. Whether performance governor is faster than powersave governor is not even clear. https://www.phoronix.com/scan.php?page=article&item=linux50-pstate- cpufreq&num=5 benchmarked them, but did not benchmark the individual energy profiles. For a desktop/laptop, the expected behavior is the powersave governor with balanced_performance on AC and balanced_power on battery. I don't know about servers or VMs, but the benchmark series seems to indicate it does not really matter much performance wise. I think most other distributions configure their kernels to use the powersave governor by default, whereas we configure it to use the performance governor and then switch it later in the boot to get the maximum performance duri
[Touch-packages] [Bug 1885730] Re: Please switch default, hwe, oem kernel flavours governor to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace utilities such as game-mode can be
** Changed in: linux (Ubuntu Groovy) Assignee: (unassigned) => Colin Ian King (colin-king) ** Changed in: linux (Ubuntu Groovy) Status: Triaged => 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/1885730 Title: Please switch default, hwe, oem kernel flavours governor to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace utilities such as game-mode can be later used to rev-up to to performance, or rev-down to powersave. Status in linux package in Ubuntu: In Progress Status in linux-oem-5.6 package in Ubuntu: New Status in linux-riscv package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in linux source package in Focal: Triaged Status in linux-oem-5.6 source package in Focal: New Status in linux-riscv source package in Focal: New Status in systemd source package in Focal: Fix Released Status in linux source package in Groovy: In Progress Status in linux-oem-5.6 source package in Groovy: New Status in linux-riscv source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: [Impact] * Kernel should have sensible default governor set to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y for the generic, hwe, raspi, riscv64, oem kernel flavours in Focal and Groovy+. * ondemand.service must not be shipped by systemd package * ppc64el, kvm flavour, cloud-kernels flavours should continue using performance governor. * Users should be given control to rev-up to performance, or rev-down to powersave using other tools, i.e. game-mode and/or similar CLI or GUI tools (these are scheduled to be integrated on Ubuntu platform later). [Test Case] * Boot ubuntu generic, hwe, or oem kernel * Check that default governor is ondemand * Check that ondemand.service is not active [Regression Potential] * ondemand governor is the best kernel default as recently analyzed by colin king, it gives a balance bootspeed and power, giving as responsive machines whilst not wasting power. It is the best experience we can give our users by default. [Other Info] * It is up to the user to elect/switch to powersave for maximum battery life, or to the performance for maximum processing power (i.e. gaming / computation). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+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 1885730] Re: Please switch default, hwe, oem kernel flavours governor to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace utilities such as game-mode can be
Fix sent to mailing list for review: https://lists.ubuntu.com/archives /kernel-team/2020-August/112820.html -- 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/1885730 Title: Please switch default, hwe, oem kernel flavours governor to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace utilities such as game-mode can be later used to rev-up to to performance, or rev-down to powersave. Status in linux package in Ubuntu: In Progress Status in linux-oem-5.6 package in Ubuntu: New Status in linux-riscv package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in linux source package in Focal: Triaged Status in linux-oem-5.6 source package in Focal: New Status in linux-riscv source package in Focal: New Status in systemd source package in Focal: Fix Released Status in linux source package in Groovy: In Progress Status in linux-oem-5.6 source package in Groovy: New Status in linux-riscv source package in Groovy: New Status in systemd source package in Groovy: Invalid Bug description: [Impact] * Kernel should have sensible default governor set to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y for the generic, hwe, raspi, riscv64, oem kernel flavours in Focal and Groovy+. * ondemand.service must not be shipped by systemd package * ppc64el, kvm flavour, cloud-kernels flavours should continue using performance governor. * Users should be given control to rev-up to performance, or rev-down to powersave using other tools, i.e. game-mode and/or similar CLI or GUI tools (these are scheduled to be integrated on Ubuntu platform later). [Test Case] * Boot ubuntu generic, hwe, or oem kernel * Check that default governor is ondemand * Check that ondemand.service is not active [Regression Potential] * ondemand governor is the best kernel default as recently analyzed by colin king, it gives a balance bootspeed and power, giving as responsive machines whilst not wasting power. It is the best experience we can give our users by default. [Other Info] * It is up to the user to elect/switch to powersave for maximum battery life, or to the performance for maximum processing power (i.e. gaming / computation). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1885730/+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 1894329] Re: ZFS revert from grub menu not working.
This is a useful workaround, the fundamental issue is a coreutils issue
with dd. I wonder if the coreutils maintainers can figure out why dd has
an executable stack.
** Also affects: coreutils (Ubuntu)
Importance: Undecided
Status: New
** Changed in: coreutils (Ubuntu)
Importance: Undecided => High
** Description changed:
+ @coreutils maintainers, any idea why dd is being flagged as having an
+ executable stack?
+
+
+
When I try to revert to a previous state from the grub menu, the boot
fails. The system drops me to a repair modus.
zfs-mount-generator fails with the message:
couldn't ensure boot: Mounted clone bootFS dataset created by initramfs
doesn't have a valid _suffix (at least .*_): \"rpool/ROOT/ubuntu_\"".
After a reboot I have an extra clone called "rpool/ROOT/ubuntu_", indeed
without a suffix.
- After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
+ After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
uid()
{
-dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
+ dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
}, the dd command fails during boot with the message "process 'dd' started
with executable stack.
After this an empty uid is returned which explains the dataset without a
proper suffix.
Replacing the function with:
uid()
{
-grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
+ grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
}
fixes the problem.
Ubuntu version is:
Description:Ubuntu Groovy Gorilla (development branch)
Release:20.10
zfs-initramfs version is:
0.8.4-1ubuntu11
With regards,
Usarin Heininga
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: zfs-initramfs 0.8.4-1ubuntu11
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Sep 4 20:23:44 2020
InstallationDate: Installed on 2020-09-02 (2 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200831)
ProcEnviron:
- LANGUAGE=
- PATH=(custom, no user)
- XDG_RUNTIME_DIR=
- LANG=nl_NL.UTF-8
- SHELL=/bin/bash
+ LANGUAGE=
+ PATH=(custom, no user)
+ XDG_RUNTIME_DIR=
+ LANG=nl_NL.UTF-8
+ SHELL=/bin/bash
SourcePackage: zfs-linux
UpgradeStatus: No upgrade log present (probably fresh install)
** Changed in: zfs-linux (Ubuntu)
Status: New => Confirmed
** Changed in: zfs-linux (Ubuntu)
Status: Confirmed => Triaged
** Changed in: coreutils (Ubuntu)
Status: New => Incomplete
** Also affects: zsys (Ubuntu)
Importance: Undecided
Status: New
** Changed in: zsys (Ubuntu)
Importance: Undecided => High
--
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/1894329
Title:
ZFS revert from grub menu not working.
Status in coreutils package in Ubuntu:
Incomplete
Status in zfs-linux package in Ubuntu:
Triaged
Status in zsys package in Ubuntu:
New
Bug description:
@coreutils maintainers, any idea why dd is being flagged as having an
executable stack?
When I try to revert to a previous state from the grub menu, the boot
fails. The system drops me to a repair modus.
zfs-mount-generator fails with the message:
couldn't ensure boot: Mounted clone bootFS dataset created by initramfs
doesn't have a valid _suffix (at least .*_): \"rpool/ROOT/ubuntu_\"".
After a reboot I have an extra clone called "rpool/ROOT/ubuntu_", indeed
without a suffix.
After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
uid()
{
dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
}, the dd command fails during boot with the message "process 'dd' started
with executable stack.
After this an empty uid is returned which explains the dataset without a
proper suffix.
Replacing the function with:
uid()
{
grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
}
fixes the problem.
Ubuntu version is:
Description:Ubuntu Groovy Gorilla (development branch)
Release:20.10
zfs-initramfs version is:
0.8.4-1ubuntu11
With regards,
Usarin Heininga
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: zfs-initramfs 0.8.4-1ubuntu11
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
NonfreeKernelModules: zfs zunic
[Touch-packages] [Bug 1895631] [NEW] systemd at 100% handling apport failures
Public bug reported: systemd is pegged at 100% after booting Groovy Desktop. Seems like an apport-report.service issue: Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. I removed apport to resolve the issue. ** Affects: systemd (Ubuntu) Importance: Medium Status: New ** Changed in: systemd (Ubuntu) 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/1895631 Title: systemd at 100% handling apport failures Status in systemd package in Ubuntu: New Bug description: systemd is pegged at 100% after booting Groovy Desktop. Seems like an apport-report.service issue: Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. I removed apport to resolve the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895631/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
I can't install Kinetic server from the LiveCD because of this issue. It's just broken. ** Also affects: systemd (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Lunar) Importance: Critical Status: Incomplete -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Kinetic: New Status in systemd source package in Lunar: Incomplete Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
This looks related: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1754328 -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Kinetic: New Status in systemd source package in Lunar: Incomplete Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
systemd error is being emitted from dispatch_notify_event() in src/journal/journald-server.c, which is called from server_connect_notify(). This function contains a large hunk of comment block describing a potential race condition. I wonder if this is some kind of race condition that only occurs on some systems due to boot speed, in this case, emulated powerpc in QEMU. -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Kinetic: New Status in systemd source package in Lunar: Incomplete Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1894329] Re: ZFS revert from grub menu not working.
I tested this out with focal -proposed and don't see any issues. Looks
OK to me.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
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/1894329
Title:
ZFS revert from grub menu not working.
Status in coreutils package in Ubuntu:
Incomplete
Status in zfs-linux package in Ubuntu:
Fix Released
Status in coreutils source package in Focal:
Incomplete
Status in zfs-linux source package in Focal:
Fix Committed
Status in coreutils source package in Groovy:
Incomplete
Status in zfs-linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users can’t revert to previous snapshots when enabling the hw enablement
stack kernel on focal or using any more recent version.
* The option is available on grub and will let you with a broken system,
partially cloned.
[Test Case]
* Boot on a system, using ZFS and ZSys.
* In grub, select "History" entry
* Select one of the "Revert" option: the system should boot after being
reverted with an older version.
[Where problems could occur]
* The code is in the initramfs, where the generated id suffix for all our
ZFS datasets was empty due to new coreutils/kernels.
* We replace dd with another way (more robust and simple) for generating
this ID.
-
@coreutils maintainers, any idea why dd is being flagged as having an
executable stack?
When I try to revert to a previous state from the grub menu, the boot
fails. The system drops me to a repair modus.
zfs-mount-generator fails with the message:
couldn't ensure boot: Mounted clone bootFS dataset created by initramfs
doesn't have a valid _suffix (at least .*_): \"rpool/ROOT/ubuntu_\"".
After a reboot I have an extra clone called "rpool/ROOT/ubuntu_", indeed
without a suffix.
After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
uid()
{
dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
}, the dd command fails during boot with the message "process 'dd' started
with executable stack.
After this an empty uid is returned which explains the dataset without a
proper suffix.
Replacing the function with:
uid()
{
grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
}
fixes the problem.
Ubuntu version is:
Description:Ubuntu Groovy Gorilla (development branch)
Release:20.10
zfs-initramfs version is:
0.8.4-1ubuntu11
With regards,
Usarin Heininga
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: zfs-initramfs 0.8.4-1ubuntu11
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Sep 4 20:23:44 2020
InstallationDate: Installed on 2020-09-02 (2 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200831)
ProcEnviron:
LANGUAGE=
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=nl_NL.UTF-8
SHELL=/bin/bash
SourcePackage: zfs-linux
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1894329/+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 1992979] Re: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected
Why won't fix? It occurs on other releases too. -- 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/1992979 Title: kinetic ppc64le reporting Failed to send WATCHDOG=1 notification message: Transport endpoint is not connected Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Kinetic: Won't Fix Status in systemd source package in Lunar: Incomplete Bug description: Upgraded from Jammy to Kinetic (14 Oct 2022) on ppc64le in QEMU, single CPU, 1GB memory, rebooted, can NO longer login. Stuck in systems boot phase. Attached is an image of the hang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1992979/+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 1847765] [NEW] network manager using small timeout polling timeouts
Public bug reported: I've been trying to identify wakeup events that cause the CPU to wakeup from idle on a "idle" laptop on Ubuntu Eoan. The good news is that NetworkManager doesn't utilize much CPU when idle, however, it does seem to wakeup from poll()/epool_wait() system calls once every 4-5 seconds on timer timeouts and I was wondering if those are necessary as they keep the CPU from being idle. I ran heath-check [1] for 1 hour to monitor NetworkManager. See the attached output. Look at the "Top polling system calls:" section and you see that poll() and epoll_wait() are polling with timeouts set to be 0.0 seconds, 6.0 and 4.0 seconds. Also look at the "Polling system call analysis:" section and you see a breakdown of the poll()/epoll_wait() calls. Recommendation: 1. Are the 4.0/6.0 poll waits necessary? Why a timeout every 4.0/6.0 seconds? 2. Why are there so many polls with zero timeouts? These normally occur when a quick peek at busy pool events on file descriptors occurs. Are these necessary? Anyhow, this is quite low in priority, but it would be nice to get investigated and fixed just to reduce CPU wakeups. References [1] https://kernel.ubuntu.com/~cking/health-check/ ** Affects: network-manager (Ubuntu) Importance: Low Status: New ** Attachment added: "network manager health-check report log file." https://bugs.launchpad.net/bugs/1847765/+attachment/5296572/+files/network-manager-health-check.log ** Changed in: network-manager (Ubuntu) Importance: Undecided => Low ** Summary changed: - network manager using non-blocking zero timeout polling + network manager using small timeout polling timeouts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1847765 Title: network manager using small timeout polling timeouts Status in network-manager package in Ubuntu: New Bug description: I've been trying to identify wakeup events that cause the CPU to wakeup from idle on a "idle" laptop on Ubuntu Eoan. The good news is that NetworkManager doesn't utilize much CPU when idle, however, it does seem to wakeup from poll()/epool_wait() system calls once every 4-5 seconds on timer timeouts and I was wondering if those are necessary as they keep the CPU from being idle. I ran heath-check [1] for 1 hour to monitor NetworkManager. See the attached output. Look at the "Top polling system calls:" section and you see that poll() and epoll_wait() are polling with timeouts set to be 0.0 seconds, 6.0 and 4.0 seconds. Also look at the "Polling system call analysis:" section and you see a breakdown of the poll()/epoll_wait() calls. Recommendation: 1. Are the 4.0/6.0 poll waits necessary? Why a timeout every 4.0/6.0 seconds? 2. Why are there so many polls with zero timeouts? These normally occur when a quick peek at busy pool events on file descriptors occurs. Are these necessary? Anyhow, this is quite low in priority, but it would be nice to get investigated and fixed just to reduce CPU wakeups. References [1] https://kernel.ubuntu.com/~cking/health-check/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1847765/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
A fix has landed in lxd, I refer you to the following comment: https://github.com/lxc/lxd/issues/4656#issuecomment-541266681 Please check if this addresses the issues. -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in lxc source package in Disco: New Status in linux source package in Eoan: Triaged Status in lxc source package in Eoan: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.l
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
** Changed in: linux-azure (Ubuntu) Assignee: Colin Ian King (colin-king) => (unassigned) -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Invalid Bug description: Very occasionally systemd panics on reboots of an azure instance. A workaround to this issue is described in comment #20 Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance
@Finom, that's a good observation, much appreciated. ** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Dimitri John Ledkov (xnox) ** Description changed: - Description: In the event a particular Azure cloud instance is - rebooted it's possible that it may never recover and the instance will - break indefinitely. + Very occasionally systemd panics on reboots of an azure instance. A + workaround to this issue is described in comment #20 + + + + + + Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. - Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - - I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. + I had a simple script to reboot an instance (X) amount of times, I chose + 50, so the machine would power cycle by issuing a "reboot" from the + terminal prompt just as a user would. Once the machine came up, it + captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. - [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- - this only occurred once in my testing. -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Confirmed Bug description: Very occasionally systemd panics on reboots of an azure instance. A workaround to this issue is described in comment #20 Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 09
[Touch-packages] [Bug 1931725] [NEW] initramfs-tools: use zstd as the default compression method
Public bug reported: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Seth Forshee (sforshee) Status: New ** Attachment added: "Libreoffice spread sheet with supporting data" https://bugs.launchpad.net/bugs/1931725/+attachment/5504114/+files/zstd-vs-lz4-initramfs-kernel-benchmarks.ods ** Description changed: Turns out that loading is always the slow part in loading initramfs into - memory, decompression is always the final 10-20% or so of the task. It - therefore makes sense to use the a good compressor that shrinks the - initramfs as much as possible with little decompression overhead. + memory and decompressing it since decompression is always the final + 10-20% or so of the task. It therefore makes sense to use a good + compressor that shrinks the initramfs as much as possible with little + decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). ** Description changed: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in - decompression the image size is much smaller with zstd than lz4, and + decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Seth Forshee (sforshee) -- 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/1931725 Title: initramfs-tools: u
[Touch-packages] [Bug 1931725] Re: initramfs-tools: use zstd as the default compression method
Thanks Dimitri! -- 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/1931725 Title: initramfs-tools: use zstd as the default compression method Status in initramfs-tools package in Ubuntu: Fix Committed Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1931725/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
This appears not to be a kernel issue per-se, so any idea of an ETA for a fix with udev for this? -- 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/1861941 Title: bcache by-uuid links disappear after mounting bcache0 Status in linux package in Ubuntu: Incomplete Status in linux-signed package in Ubuntu: New Status in systemd package in Ubuntu: New Status in linux source package in Focal: New Status in linux-signed source package in Focal: New Status in systemd source package in Focal: New Status in linux source package in Groovy: Incomplete Status in linux-signed source package in Groovy: New Status in systemd source package in Groovy: New Bug description: 1. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 2. root@ubuntu:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 root@ubuntu:~# apt-cache policy linux-image-virtual linux-image-virtual: Installed: 5.4.0.12.15 Candidate: 5.4.0.12.15 Version table: *** 5.4.0.12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic linux-image-5.4.0-12-generic: Installed: 5.4.0-12.15 Candidate: 5.4.0-12.15 Version table: *** 5.4.0-12.15 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status 3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/ + ls -al /dev/bcache/by-uuid/ total 0 drwxr-xr-x 2 root root 60 Feb 4 23:31 . drwxr-xr-x 3 root root 60 Feb 4 23:31 .. lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0 4. root@ubuntu:~# ls -al /dev/bcache/by-uuid ls: cannot access '/dev/bcache/by-uuid': No such file or directory ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-12-generic 5.4.0-12.15 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 23:31:52 2020 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-5.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861941/+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 1505241] Re: Phone does not suspend
>From the syslog in comment #2, Suspend blocking wakelocks: None Resume wakeup causes: EINT, 553 97.88% CLDMA_MD6 1.06% CLDMA_MD, 6 1.06% Suspend failure causes: tasks freezer abort 2548 99.96% devices failed to suspend 1 0.04% Time between successful suspends: Interval (seconds) FrequencyCumulative Time (Seconds) 0.500 -0.999222 39.78% 207.71 1.64% 1.000 -1.999222 39.78% 324.46 2.56% 2.000 -3.999 69 12.37% 186.37 1.47% 4.000 -7.999 33 5.91% 177.43 1.40% 8.000 - 15.999 4 0.72% 32.98 0.26% 16.000 - 31.999 0 0.00% 0.00 0.00% 32.000 - 63.999 1 0.18% 54.62 0.43% 64.000 - 127.999 1 0.18% 127.39 1.01% 128.000 - 255.999 0 0.00% 0.00 0.00% 256.000 - 511.999 2 0.36% 632.91 5.00% 512.000 - 1023.999 1 0.18%1014.42 8.02% 1024.000 - 2047.999 1 0.18%1989.64 15.72% 2048.000 - 4095.999 1 0.18%2373.90 18.76% 4096.000 - 8191.999 1 0.18%5532.61 43.72% Duration of successful suspends: Interval (seconds) FrequencyCumulative Time (Seconds) 0.250 -0.499 7 1.25% 2.70 0.04% 0.500 -0.999 15 2.68% 11.42 0.18% 1.000 -1.999 22 3.94% 31.21 0.48% 2.000 -3.999 68 12.16% 192.50 2.98% 4.000 -7.999340 60.82%1959.54 30.29% 8.000 - 15.999 12 2.15% 139.92 2.16% 16.000 - 31.999 31 5.55% 705.55 10.91% 32.000 - 63.999 53 9.48%2672.92 41.32% 64.000 - 127.999 11 1.97% 752.79 11.64% Suspends: 2584 suspends aborted (82.21%). 559 suspends succeeded (17.79%). total time: 6468.553336 seconds (33.83%). minimum: 0.333752 seconds. maximum: 106.062716 seconds. mean: 11.571652 seconds. mode: 6.00 seconds. median: 5.974301 seconds. Time between successful suspends: total time: 12654.471830 seconds (66.17%). minimum: 0.898421 seconds. maximum: 5532.614185 seconds. mean: 22.678265 seconds. mode: 1.00 seconds. median: 1.155373 seconds. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1505241 Title: Phone does not suspend Status in Canonical System Image: Invalid Status in bluez package in Ubuntu: In Progress Bug description: I am seeing both the MX4 on proposed and the E4.5 on stable exhibit similar behavior According to the logs they are not able to suspend due to active wakeup sources. (I am running a BT test kernel on the MX4 3.10.35+) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1505241/+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 1524879] [NEW] initramfs-tools, Xenial is missing NVME kernel driver
Public bug reported: I can't boot from a PCIe NVME device on Xenial because the nvme.ko is missing from the initramfs. Can this please be added. ** Affects: initramfs-tools (Ubuntu) Importance: High Assignee: Andy Whitcroft (apw) Status: New ** Changed in: initramfs-tools (Ubuntu) Assignee: (unassigned) => Andy Whitcroft (apw) ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => High -- 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/1524879 Title: initramfs-tools, Xenial is missing NVME kernel driver Status in initramfs-tools package in Ubuntu: New Bug description: I can't boot from a PCIe NVME device on Xenial because the nvme.ko is missing from the initramfs. Can this please be added. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1524879/+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 1696970] Re: softlockup DoS causes systemd-journald.service to abort with SIGABORT
Hrm, softlockups that break the journal aren't particularly rare on highly loaded servers. I'm a little concerned that a potential user space DoS attack could cause the log to discard important information that the system admin may use to help track down misbehaving system behaviour. -- 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/1696970 Title: softlockup DoS causes systemd-journald.service to abort with SIGABORT Status in systemd package in Ubuntu: Opinion Status in systemd source package in Artful: Opinion Bug description: I was running the new stress-ng softlockup stressor and observed that systemd-journald gets killed with an abort and this corrupts the systemd journal. How to reproduce: git clone git://kernel.ubuntu.com/cking/stress-ng cd stress-ng make clean; make sudo ./stress-ng --softlockup 0 -t 360 -v ..and wait for 360 seconds. dmesg shows the following, 100% reproduceable: [ 875.310331] systemd[1]: systemd-timesyncd.service: Watchdog timeout (limit 3min)! [ 875.310740] systemd[1]: systemd-timesyncd.service: Killing process 574 (systemd-timesyn) with signal SIGABRT. [ 875.327289] systemd[1]: systemd-timesyncd.service: Main process exited, code=killed, status=6/ABRT [ 875.327666] systemd[1]: systemd-timesyncd.service: Unit entered failed state. [ 875.327686] systemd[1]: systemd-timesyncd.service: Failed with result 'watchdog'. [ 875.327917] systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. [ 875.327954] systemd[1]: Stopped Network Time Synchronization. [ 875.328845] systemd[1]: Starting Network Time Synchronization... [ 875.525071] systemd[1]: Started Network Time Synchronization. [ 875.539619] systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=6/ABRT [ 875.544257] systemd-journald[5214]: File /run/log/journal/440e485e550040e3b93b66b2faae8525/system.journal corrupted or uncleanly shut down, renaming and replacing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1696970/+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 1784583] [NEW] SIGILL on s390x in libpthread when run inside cosmic VM
Public bug reported: I installed the Cosmic s390x server on an x86-64 Cosmic host using virt manager and get a SIGILL when using libptread. For example: I built stress-ng from the upstream git repo using: sudo apt-get build-dep stress-ng git clone git://kernel.ubuntu.com/cking/stress-ng cd stress-ng make ./stress-ng --help [66597.487332] User process fault: interruption code 0002 ilc:2 Illegal instruction Debugging this with gdb one can see the SIGILL occurs in libpthread: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x03fffdffe71c in __kernel_getcpu () (gdb) where #0 0x03fffdffe71c in __kernel_getcpu () #1 0x03fffd8699a4 in sched_getcpu () at ../sysdeps/unix/sysv/linux/sched_getcpu.c:32 #2 0x02aa000ea96e in stress_get_cpu () at helper.c:1064 #3 0x02aa000edef6 in mwc_reseed () at mwc.c:70 #4 0x02aa000f7d5a in main (argc=1, argv=0x3fffb98) at stress-ng.c:3477 cat /proc/cpuinfo vendor_id : IBM/S390 # processors: 4 bogomips per cpu: 13370.00 max thread id : 0 features: esan3 zarch stfle msa ldisp eimm etf3eh highgprs facilities : 0 1 2 3 4 7 9 16 17 18 19 21 22 24 25 27 30 31 32 33 34 35 40 41 45 49 51 52 71 72 76 77 138 processor 0: version = 00, identification = 00, machine = 2827 processor 1: version = 00, identification = 40, machine = 2827 processor 2: version = 00, identification = 80, machine = 2827 processor 3: version = 00, identification = C0, machine = 2827 However, the same code runs perfectly OK on a s390 cosmic VM on a s390 host, cpu info of this is: vendor_id : IBM/S390 # processors: 2 bogomips per cpu: 3033.00 max thread id : 0 features: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx facilities : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 46 47 48 49 50 51 52 53 55 57 73 75 76 77 78 80 81 82 129 cache0 : level=1 type=Data scope=Private size=128K line_size=256 associativity=8 cache1 : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6 cache2 : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8 cache3 : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8 cache4 : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16 cache5 : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30 processor 0: version = FF, identification = 258F67, machine = 2964 processor 1: version = FF, identification = 258F67, machine = 2964 cpu number : 0 cpu MHz dynamic : 5000 cpu MHz static : 5000 cpu number : 1 cpu MHz dynamic : 5000 cpu MHz static : 5000 So I think this must be to do with the s390x VM on a x86-64 host. ** Affects: eglibc (Ubuntu) Importance: Medium Status: New ** Changed in: eglibc (Ubuntu) Importance: Undecided => Medium -- 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/1784583 Title: SIGILL on s390x in libpthread when run inside cosmic VM Status in eglibc package in Ubuntu: New Bug description: I installed the Cosmic s390x server on an x86-64 Cosmic host using virt manager and get a SIGILL when using libptread. For example: I built stress-ng from the upstream git repo using: sudo apt-get build-dep stress-ng git clone git://kernel.ubuntu.com/cking/stress-ng cd stress-ng make ./stress-ng --help [66597.487332] User process fault: interruption code 0002 ilc:2 Illegal instruction Debugging this with gdb one can see the SIGILL occurs in libpthread: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x03fffdffe71c in __kernel_getcpu () (gdb) where #0 0x03fffdffe71c in __kernel_getcpu () #1 0x03fffd8699a4 in sched_getcpu () at ../sysdeps/unix/sysv/linux/sched_getcpu.c:32 #2 0x02aa000ea96e in stress_get_cpu () at helper.c:1064 #3 0x02aa000edef6 in mwc_reseed () at mwc.c:70 #4 0x02aa000f7d5a in main (argc=1, argv=0x3fffb98) at stress-ng.c:3477 cat /proc/cpuinfo vendor_id : IBM/S390 # processors: 4 bogomips per cpu: 13370.00 max thread id : 0 features : esan3 zarch stfle msa ldisp eimm etf3eh highgprs facilities : 0 1 2 3 4 7 9 16 17 18 19 21 22 24 25 27 30 31 32 33 34 35 40 41 45 49 51 52 71 72 76 77 138 processor 0: version = 00, identification = 00, machine = 2827 processor 1: version = 00, identification = 40, machine = 2827 processor 2: version = 00, identification
[Touch-packages] [Bug 1821625] Re: systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test-seccomp)
I agree with the analysis in comment #13 about stress-ng.
--
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/1821625
Title:
systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test-
seccomp)
Status in libseccomp package in Ubuntu:
Invalid
Status in linux package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Invalid
Status in libseccomp source package in Bionic:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in systemd source package in Bionic:
Invalid
Bug description:
Starting with systemd 237-3ubuntu10.14, the testcase test-seccomp is
failing on Bionic on ppc64el with the error messages:
Operating on architecture: ppc
Failed to add n/a() rule for architecture ppc, skipping: Bad address
Operating on architecture: ppc64
Failed to add n/a() rule for architecture ppc64, skipping: Bad address
Operating on architecture: ppc64-le
Failed to add n/a() rule for architecture ppc64-le, skipping: Numerical
argument out of domain
Assertion 'p == MAP_FAILED' failed at ../src/test/test-seccomp.c:413,
function test_memory_deny_write_execute_mmap(). Aborting.
memoryseccomp-mmap terminated by signal ABRT.
Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG)
== EXIT_SUCCESS' failed at ../src/test/test-seccomp.c:427, function
test_memory_deny_write_execute_mmap(). Aborting.
Aborted (core dumped)
FAIL: test-seccomp (code: 134)
Full logs at:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/s/systemd/20190302_025135_d0e38@/log.gz
The testcase passed with systemd version 237-3ubuntu10.13 running on the same
4.15.0-45 kernel on ppc64el:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/s/systemd/20190228_154406_6b12f@/log.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1821625/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
Cosmic is now end-of-life. Does this still occur on Disco? ** Changed in: linux (Ubuntu) Importance: High => Medium ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Colin Ian King (colin-king) -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
Do we have any hunches on how to reproduce this issue? -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
Reproducer is as follows: lxc launch ubuntu:bionic zfs-bug-test Creating zfs-bug-test Starting zfs-bug-test lxc delete zfs-bug-test --force Error: Failed to destroy ZFS filesystem: Can reproduce this on Eoan with latest 5.2, 5.3 kernel. ** Also affects: linux (Ubuntu Eoan) Importance: Medium Assignee: Colin Ian King (colin-king) Status: Triaged ** Also affects: lxc (Ubuntu Eoan) Importance: Undecided Status: Confirmed ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Disco) Importance: Undecided Status: New -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in lxc source package in Disco: New Status in linux source package in Eoan: Triaged Status in lxc source package in Eoan: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246
[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
The ZFS destroy checks the reference count on the dataset with zfs_refcount_count(&ds->ds_longholds) != expected_holds and returns EBUSY in dsl_destroy_head_check_impl. -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in lxc source package in Disco: New Status in linux source package in Eoan: Triaged Status in lxc source package in Eoan: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version: � dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr: dmi.product.family: � dmi.product.name: � dmi.product.version: � dmi.sys.vendor: � To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.la
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
@Joseph, any ideas how we can progress on this? -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance
** Changed in: linux-azure (Ubuntu) Status: In Progress => Incomplete -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance
@Robert, was there a specific class of virtual machine you were using when this issue occurred? -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
Been digging into this a bit further with lxc 3.17 on Eoan. lxc launch ubuntu:bionic zfs-bug-test Creating zfs-bug-test Starting zfs-bug-test lxc delete zfs-bug-test --force Error: Failed to destroy ZFS filesystem: Failed to run: zfs destroy -r default/containers/z1: cannot destroy 'default/containers/z1': dataset is busy However, re-running the delete works fine: lxd.lxc delete z1 --force Looking at system calls, it appears that the first failing delete --force command attempts to destroy the zfs file system multiple times and then gives up. In doing so, it umounts the zfs file system. Hence the second time the delete is issued it works fine because zfs is now umounted. So it appears that the ordering in the delete is not as it expected. It seems to do: zfs destroy x 10 (or so and then gives up because of errno 16 -EBUSY) zfs umount It should be doing: zfs umount zfs destroy This matches the observed reference counting. The ref count is only dropped once the umount is complete. Attempts to destroy it before that will cause an -EBUSY. -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in lxc source package in Disco: New Status in linux source package in Eoan: Triaged Status in lxc source package in Eoan: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: ��
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
IP addr Mac AddrKernel Reboots 13.64.67.18600:0d:3a:3a:dd:04 5.0.0-1016-azure50 104.42.152.115 00:0d:3a:35:b1:e6 5.0.0-1016-azure50 65.52.121.205 00:0d:3a:3b:0f:52 5.0.0-1016-azure50 13.88.28.42 00:0d:3a:3b:c7:da 5.0.0-1016-azure50 40.118.165.237 00:0d:3a:3b:c2:4e 5.0.0-1016-azure50 40.118.190.105 00:0d:3a:36:c6:d7 5.0.0-1016-azure50 40.78.90.95 00:0d:3a:37:c0:d9 5.0.0-1016-azure50 13.83.84.15000:0d:3a:37:c0:15 5.0.0-1016-azure50 104.42.74.129 00:0d:3a:36:c2:3e 5.0.0-1016-azure50 40.85.154.162 00:0d:3a:37:cc:dd 5.0.0-1016-azure50 40.78.43.4 00:0d:3a:37:c5:07 5.0.0-1016-azure50 13.93.142.147 00:0d:3a:37:c8:5f 5.0.0-1016-azure50 40.78.44.22900:0d:3a:3b:e4:80 5.0.0-1016-azure50 40.118.189.62 00:0d:3a:3b:e8:8e 5.0.0-1016-azure50 40.78.85.10 00:0d:3a:3b:e6:37 5.0.0-1016-azure50 40.78.13.20300:0d:3a:3a:c2:b0 5.0.0-1016-azure50 104.42.112.81 00:0d:3a:30:71:fb 5.0.0-1016-azure50 40.80.156.132 00:0d:3a:30:2f:7c 5.0.0-1016-azure50 13.64.173.138 00:0d:3a:30:73:b2 5.0.0-1016-azure50 13.64.189.105 00:0d:3a:30:a4:6f 5.0.0-1016-azure50 13.64.189.127 00:0d:3a:30:a4:1f 5.0.0-1016-azure50 104.45.237.232 00:0d:3a:32:1e:3b 5.0.0-1016-azure50 104.42.233.11 00:0d:3a:32:34:68 5.0.0-1016-azure50 104.42.233.20 00:0d:3a:34:ed:42 5.0.0-1016-azure50 23.101.202.206 00:0d:3a:32:32:b0 5.0.0-1016-azure50 104.42.233.18 00:0d:3a:34:ee:ba 5.0.0-1016-azure50 104.42.233.151 00:0d:3a:34:e9:0d 5.0.0-1016-azure50 104.40.51.248 00:0d:3a:32:27:c6 5.0.0-1016-azure50 104.40.69.158 00:0d:3a:34:f1:5d 5.0.0-1016-azure50 52.160.41.9500:0d:3a:35:9f:c8 5.0.0-1016-azure50 104.42.158.74 00:0d:3a:34:c7:91 5.0.0-1016-azure50 IP addr Mac AddrKernel Reboots 40.83.145.235 00:0d:3a:5a:01:f9 5.0.0-1016-azure250 104.210.50.91 00:0d:3a:35:b2:48 5.0.0-1016-azure250 13.88.186.166 00:0d:3a:5a:0b:86 5.0.0-1016-azure250 40.118.185.194 00:0d:3a:35:b9:59 5.0.0-1016-azure250 104.42.37.175 00:0d:3a:5a:06:ff 5.0.0-1016-azure250 13.88.186.188 00:0d:3a:5a:05:da 5.0.0-1016-azure250 104.210.48.49 00:0d:3a:35:b8:a7 5.0.0-1016-azure250 104.210.50.215 00:0d:3a:35:ba:13 5.0.0-1016-azure250 40.78.52.50 00:0d:3a:35:b6:50 5.0.0-1016-azure250 40.118.186.25 00:0d:3a:35:b5:93 5.0.0-1016-azure250 13.93.233.2600:0d:3a:37:06:7e 5.0.0-1016-azure156 crashed 13.93.136.144 00:0d:3a:37:0e:2f 5.0.0-1016-azure250 40.118.241.192 00:0d:3a:32:c4:5d 5.0.0-1016-azure250 40.83.160.5200:0d:3a:37:47:48 5.0.0-1016-azure250 104.42.9.61 00:0d:3a:36:d3:a0 5.0.0-1016-azure250 IP addr Mac AddrKernel Reboots 104.40.1.50 00:0d:3a:30:8d:ae 5.0.0-1016-azure500 104.40.3.20500:0d:3a:30:81:d5 5.0.0-1016-azure500 104.40.9.37 00:0d:3a:30:86:bb 5.0.0-1016-azure500 104.40.0.24200:0d:3a:30:88:6b 5.0.0-1016-azure500 104.40.12.184 00:0d:3a:30:8e:e0 5.0.0-1016-azure500 137.135.46.72 00:0d:3a:30:ac:df 5.0.0-1016-azure500 137.135.47.169 00:0d:3a:30:9a:3f 5.0.0-1016-azure500 104.40.10.226 00:0d:3a:30:2d:fb 5.0.0-1016-azure500 104.40.10.244 00:0d:3a:30:8e:12 5.0.0-1016-azure500 104.40.15.160 00:0d:3a:30:87:4d 5.0.0-1016-azure500 40.112.132.200:0d:3a:59:b5:80 5.0.0-1016-azure500 13.64.97.59 00:0d:3a:59:b1:e7 5.0.0-1016-azure500 40.78.19.22400:0d:3a:5a:bd:99 5.0.0-1016-azure500 13.64.88.51 00:0d:3a:37:30:07 5.0.0-1016-azure500 40.118.225.110 00:0d:3a:59:b1:8f 5.0.0-1016-azure500 -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Ne
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
See above, I ran several thousand reboot tests on a lot of Basic_A3 instances, ranging from 50, 250 to 500 reboots. Only one failed. So this is *really* hard to reproduce. -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance
I kicked off another ~20K reboot tests with Standard_B2S instances and hit hangs again: IP addr Mac AddrKernel Reboots 104.42.3.16100:0d:3a:37:82:ee 5.0.0-1020-azure100 13.91.5.23 00:0d:3a:5a:74:23 5.0.0-1020-azure57 [ HANG ] 13.91.5.222 00:0d:3a:5a:75:1a 5.0.0-1020-azure100 13.64.117.146 00:0d:3a:5a:74:da 5.0.0-1020-azure100 13.64.117.1700:0d:3a:37:67:0e 5.0.0-1020-azure100 13.91.6.207 00:0d:3a:3a:cc:2c 5.0.0-1020-azure100 40.78.30.12900:0d:3a:36:6e:eb 5.0.0-1020-azure100 104.210.36.238 00:0d:3a:5a:73:da 5.0.0-1020-azure100 13.91.6.143 00:0d:3a:3a:c8:ec 5.0.0-1020-azure100 40.83.249.5800:0d:3a:3a:c0:7a 5.0.0-1020-azure100 104.45.216.53 00:0d:3a:3b:8a:55 5.0.0-1020-azure100 104.210.42.18 00:0d:3a:5a:73:5c 5.0.0-1020-azure100 40.78.27.21 00:0d:3a:3a:c9:19 5.0.0-1020-azure100 40.83.252.110 00:0d:3a:5a:79:93 5.0.0-1020-azure100 13.64.119.204 00:0d:3a:5a:7e:bc 5.0.0-1020-azure100 104.210.34.400:0d:3a:31:18:ee 5.0.0-1020-azure250 138.91.197.202 00:0d:3a:31:1d:c1 5.0.0-1020-azure94 [ HANG ] 138.91.196.241 00:0d:3a:31:15:2b 5.0.0-1020-azure250 104.210.33.44 00:0d:3a:31:16:f3 5.0.0-1020-azure250 40.83.248.7600:0d:3a:32:af:a7 5.0.0-1020-azure250 40.83.253.204 00:0d:3a:32:ba:09 5.0.0-1020-azure250 168.62.202.800:0d:3a:32:a0:11 5.0.0-1020-azure250 40.83.249.8 00:0d:3a:32:bd:ce 5.0.0-1020-azure250 40.83.249.9300:0d:3a:32:b7:32 5.0.0-1020-azure250 40.83.253.187 00:0d:3a:32:b9:cd 5.0.0-1020-azure250 23.99.9.88 00:0d:3a:37:96:c9 5.0.0-1020-azure250 104.40.29.184 00:0d:3a:36:9f:e0 5.0.0-1020-azure250 137.135.40.122 00:0d:3a:36:9f:eb 5.0.0-1020-azure250 137.135.49.43 00:0d:3a:36:92:aa 5.0.0-1020-azure250 138.91.251.800:0d:3a:37:9e:ef 5.0.0-1020-azure250 13.64.146.175 00:0d:3a:31:de:ee 5.0.0-1020-azure500 104.42.23.145 00:0d:3a:31:da:d7 5.0.0-1020-azure500 104.42.29.9900:0d:3a:31:d4:4f 5.0.0-1020-azure500 40.78.106.1200:0d:3a:31:d9:8a 5.0.0-1020-azure500 138.91.233.210 00:0d:3a:31:df:84 5.0.0-1020-azure500 104.42.25.3000:0d:3a:31:c9:a4 5.0.0-1020-azure500 13.64.150.6900:0d:3a:31:dd:47 5.0.0-1020-azure321 [ HANG ] 104.42.25.2300:0d:3a:31:d3:c9 5.0.0-1020-azure500 104.42.24.176 00:0d:3a:31:d8:36 5.0.0-1020-azure500 13.64.79.13300:0d:3a:31:d5:b4 5.0.0-1020-azure500 104.42.29.146 00:0d:3a:31:de:73 5.0.0-1020-azure500 104.42.19.191 00:0d:3a:31:d4:78 5.0.0-1020-azure500 40.118.249.118 00:0d:3a:31:db:20 5.0.0-1020-azure500 40.112.219.112 00:0d:3a:31:dc:da 5.0.0-1020-azure500 104.42.17.115 00:0d:3a:31:d3:21 5.0.0-1020-azure500 40.83.212.164 00:0d:3a:5a:ab:48 5.0.0-1020-azure500 52.160.123.400:0d:3a:36:0d:6a 5.0.0-1020-azure500 52.160.83.3700:0d:3a:5a:ab:79 5.0.0-1020-azure500 52.160.122.92 00:0d:3a:36:00:4c 5.0.0-1020-azure500 52.160.122.71 00:0d:3a:36:0f:bd 5.0.0-1020-azure500 52.160.123.12 00:0d:3a:36:04:39 5.0.0-1020-azure500 104.210.60.218 00:0d:3a:36:b6:25 5.0.0-1020-azure500 52.160.123.221 00:0d:3a:5a:a9:a3 5.0.0-1020-azure500 52.160.123.234 00:0d:3a:5a:a7:1c 5.0.0-1020-azure500 104.210.61.139 00:0d:3a:37:b7:84 5.0.0-1020-azure500 104.210.61.43 00:0d:3a:36:b5:96 5.0.0-1020-azure500 40.83.212.185 00:0d:3a:5a:af:9c 5.0.0-1020-azure500 52.160.82.111 00:0d:3a:5a:a9:a9 5.0.0-1020-azure500 52.160.82.167 00:0d:3a:5a:a7:17 5.0.0-1020-azure500 104.210.61.135 00:0d:3a:36:b3:97 5.0.0-1020-azure500 -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Th
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
So the best way to reproduce this issue is to run ~500 reboots across multiple instances rather than 5000-1 reboots on once instance. -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'
See: https://github.com/lxc/lxd/issues/4656#issuecomment-535531229 In https://github.com/lxc/lxd/blob/master/lxd/storage_zfs_utils.go#L255 the umount is done by err := unix.Unmount(mountpoint, unix.MNT_DETACH) The umount2(2) manpage writes about MNT_DETACH: Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy. Could this be it? The MNT_DETACH umount looks partially asynchronous. All the subsequent destroy commands may fail because they keep the mount point busy. Finally the retry loop ends, the umount happens for real and the following destroy succeeds. — -- 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/1779156 Title: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy' Status in linux package in Ubuntu: Triaged Status in lxc package in Ubuntu: Confirmed Status in linux source package in Cosmic: Triaged Status in lxc source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in lxc source package in Disco: New Status in linux source package in Eoan: Triaged Status in lxc source package in Eoan: Confirmed Bug description: I'm not sure exactly what got me into this state, but I have several lxc containers that cannot be deleted. $ lxc info api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls environment: addresses: [] architectures: - x86_64 - i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificate_fingerprint: 3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb driver: lxc driver_version: 3.0.1 kernel: Linux kernel_architecture: x86_64 kernel_version: 4.15.0-23-generic server: lxd server_pid: 15123 server_version: "3.2" storage: zfs storage_version: 0.7.5-1ubuntu15 server_clustered: false server_name: milhouse $ lxc delete --force b1 Error: Failed to destroy ZFS filesystem: cannot destroy 'default/containers/b1': dataset is busy Talking in #lxc-dev, stgraber and sforeshee provided diagnosis: | short version is that something unshared a mount namespace causing | them to get a copy of the mount table at the time that dataset was | mounted, which then prevents zfs from being able to destroy it) The work around provided was | you can unstick this particular issue by doing: | grep default/containers/b1 /proc/*/mountinfo | then for any of the hits, do: | nsenter -t PID -m -- umount /var/snap/lxd/common/lxd/storage-pools/default/containers/b1 | then try the delete again ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.15.0-23-generic 4.15.0-23.25 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: smoser31412 F pulseaudio /dev/snd/controlC2: smoser31412 F pulseaudio /dev/snd/controlC0: smoser31412 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Thu Jun 28 10:42:45 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (1071 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) MachineType: b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.174 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2015 dmi.bios.vendor: Intel Corporation dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355 dmi.board.asset.tag: � dmi.board.name: NUC5i5RYB dmi.board.vendor: Intel Corporation dmi.board.version: H40999-503 dmi.chassis.asset.tag: � dmi.chassis.type: 3 dmi.chassis.vendor: � dmi.chassis.version:
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
Get more failures with Standard_B1ms IP addr Mac AddrKernel Reboots 52.160.101.11 00:0d:3a:5b:a0:7c 5.0.0-1020-azure10 137.135.51.101 00:0d:3a:31:20:fc 5.0.0-1020-azure500 137.135.50.133 00:0d:3a:31:27:0f 5.0.0-1020-azure396 [hang] 137.135.51.198 00:0d:3a:31:28:d7 5.0.0-1020-azure500 137.135.49.89 00:0d:3a:31:22:c1 5.0.0-1020-azure500 137.135.48.14 00:0d:3a:33:05:7d 5.0.0-1020-azure500 104.40.5.23 00:0d:3a:32:e7:27 5.0.0-1020-azure228 [hang] 13.93.223.213 00:0d:3a:32:e8:59 5.0.0-1020-azure500 104.40.0.15100:0d:3a:31:32:09 5.0.0-1020-azure500 40.118.128.130 00:0d:3a:32:f5:71 5.0.0-1020-azure500 23.101.200.119 00:0d:3a:36:c5:94 5.0.0-1020-azure500 104.40.8.52 00:0d:3a:33:07:6e 5.0.0-1020-azure500 104.40.19.222 00:0d:3a:33:01:0d 5.0.0-1020-azure500 104.42.135.72 00:0d:3a:3b:e9:15 5.0.0-1020-azure500 104.40.22.205 00:0d:3a:33:0d:d8 5.0.0-1020-azure500 104.40.7.22 00:0d:3a:37:85:ff 5.0.0-1020-azure500 13.88.17.94 00:0d:3a:5a:54:c6 5.0.0-1020-azure500 104.40.8.19600:0d:3a:59:56:f3 5.0.0-1020-azure500 13.88.21.12500:0d:3a:5a:50:00 5.0.0-1020-azure500 13.88.23.13900:0d:3a:5a:55:c3 5.0.0-1020-azure500 23.99.81.18800:0d:3a:5a:52:0f 5.0.0-1020-azure500 13.88.20.13200:0d:3a:5a:55:f1 5.0.0-1020-azure500 13.88.20.12600:0d:3a:5a:58:65 5.0.0-1020-azure500 13.88.20.23700:0d:3a:5a:55:42 5.0.0-1020-azure500 13.88.17.35 00:0d:3a:5a:57:5f 5.0.0-1020-azure500 13.91.54.22500:0d:3a:5a:57:5a 5.0.0-1020-azure500 13.88.21.57 00:0d:3a:5a:52:ce 5.0.0-1020-azure500 13.88.21.67 00:0d:3a:5a:5b:b7 5.0.0-1020-azure500 13.88.18.46 00:0d:3a:5a:5d:02 5.0.0-1020-azure229 [hang] 13.88.16.22200:0d:3a:37:80:d1 5.0.0-1020-azure500 -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug
[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance
And for Standard_D2s_v3 IP addr Mac AddrKernel Reboots 104.42.252.54 00:0d:3a:32:df:92 5.0.0-1020-azure500 104.42.150.26 00:0d:3a:31:1b:50 5.0.0-1020-azure500 104.42.147.144 00:0d:3a:32:d8:2f 5.0.0-1020-azure500 40.112.129.232 00:0d:3a:32:d5:7c 5.0.0-1020-azure500 40.112.134.251 00:0d:3a:32:d9:2d 5.0.0-1020-azure500 13.64.195.2100:0d:3a:5a:7b:51 5.0.0-1020-azure500 40.83.214.204 00:0d:3a:36:47:98 5.0.0-1020-azure500 13.64.195.2700:0d:3a:5a:7f:05 5.0.0-1020-azure500 13.64.195.3100:0d:3a:5a:78:55 5.0.0-1020-azure500 13.64.195.6900:0d:3a:5a:7c:72 5.0.0-1020-azure500 104.42.51.2300:0d:3a:37:47:0a 5.0.0-1020-azure500 13.64.233.120 00:0d:3a:37:46:ab 5.0.0-1020-azure500 13.64.233.216 00:0d:3a:37:49:fb 5.0.0-1020-azure500 13.64.239.157 00:0d:3a:37:43:cf 5.0.0-1020-azure16 [hang] 52.160.87.177 00:0d:3a:35:fc:b1 5.0.0-1020-azure500 -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1822118] Re: Kernel Panic while rebooting cloud instance
@Joseph, so I can reproduce this hang/crash issue across a variety of instances. I can't get any info back on a console, so debugging this is not easy. -- 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/1822118 Title: Kernel Panic while rebooting cloud instance Status in linux-azure package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Description: In the event a particular Azure cloud instance is rebooted it's possible that it may never recover and the instance will break indefinitely. In My case, it was a kernel panic. See specifics below.. Series: Disco Instance Size: Basic_A3 Region: (Default) US-WEST-2 Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux I had a simple script to reboot an instance (X) amount of times, I chose 50, so the machine would power cycle by issuing a "reboot" from the terminal prompt just as a user would. Once the machine came up, it captured dmesg and other bits then rebooted again until it reached 50. After the 4th attempt, my script timed out, I took a look at the instance console log and the following displayed on the console. [ OK ] Reached target Reboot. /shutdown: error while loading shared libra[ 89.498980] Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.498980] [ 89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure #13-Ubuntu [ 89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 89.508026] Call Trace: [ 89.508026] dump_stack+0x63/0x8a [ 89.508026] panic+0xe7/0x247 [ 89.508026] do_exit.cold.23+0x26/0x75 [ 89.508026] do_group_exit+0x43/0xb0 [ 89.508026] __x64_sys_exit_group+0x18/0x20 [ 89.508026] do_syscall_64+0x5a/0x110 [ 89.508026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 89.508026] RIP: 0033:0x7f7bf0154d86 [ 89.508026] Code: Bad RIP value. [ 89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 00e7 [ 89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 7f7bf0154d86 [ 89.508026] RDX: 007f RSI: 003c RDI: 007f [ 89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: [ 89.508026] R10: 7ffd6be6974c R11: 0206 R12: 0018 [ 89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: [ 89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation range: 0x8000-0xbfff) [ 89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00 [ 89.508026] ]--- this only occurred once in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 2024599] Re: linux-image-5.15.0-1032-realtime locks up under scheduler test load
On 6.2.0-21-generic I also get: sudo ./stress-ng --apparmor 1 --klog-check stress-ng: error: [1083] klog-check: alert: [66.442338] 'BUG: kernel NULL pointer dereference, address: 0030' stress-ng: error: [1083] klog-check: alert: [66.442538] '#PF: supervisor read access in kernel mode' stress-ng: error: [1083] klog-check: alert: [66.442718] '#PF: error_code(0x) - not-present page' stress-ng: info: [1083] klog-check: warning: [66.443080] 'Oops: [#1] PREEMPT SMP PTI' stress-ng: info: [1083] klog-check: warning: [66.443256] 'CPU: 3 PID: 1088 Comm: stress-ng-appar Not tainted 6.2.0-21-generic #21-Ubuntu' stress-ng: info: [1083] klog-check: warning: [66.443438] 'Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-debian-1.16.0-5 04/01/2014' stress-ng: info: [1083] klog-check: warning: [66.443628] 'RIP: 0010:aafs_create.constprop.0+0x7f/0x130' stress-ng: info: [1083] klog-check: warning: [66.443819] 'Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 8a 59 a1' stress-ng: info: [1083] klog-check: warning: [66.444227] 'RSP: 0018:beb940907bd8 EFLAGS: 00010246' stress-ng: info: [1083] klog-check: warning: [66.33] 'RAX: RBX: 41ed RCX: ' stress-ng: info: [1083] klog-check: warning: [66.444646] 'RDX: RSI: RDI: ' stress-ng: info: [1083] klog-check: warning: [66.444862] 'RBP: beb940907c18 R08: R09: ' stress-ng: info: [1083] klog-check: warning: [66.445074] 'R10: R11: R12: 93db8b18' stress-ng: info: [1083] klog-check: warning: [66.445291] 'R13: R14: R15: ' stress-ng: info: [1083] klog-check: warning: [66.445503] 'FS: 7f60f5c07740() GS:9578bbcc() knlGS:' stress-ng: info: [1083] klog-check: warning: [66.445721] 'CS: 0010 DS: ES: CR0: 80050033' stress-ng: info: [1083] klog-check: warning: [66.445939] 'CR2: 0030 CR3: 000124ffa004 CR4: 00370ee0' stress-ng: info: [1083] klog-check: warning: [66.446163] 'DR0: DR1: DR2: ' stress-ng: info: [1083] klog-check: warning: [66.446387] 'DR3: DR6: fffe0ff0 DR7: 0400' stress-ng: info: [1083] klog-check: warning: [66.446608] 'Call Trace:' stress-ng: info: [1083] klog-check: warning: [66.446829] ' ' stress-ng: info: [1083] klog-check: warning: [66.447059] ' __aafs_profile_mkdir+0x3d6/0x480' stress-ng: info: [1083] klog-check: warning: [66.447290] ' aa_replace_profiles+0x862/0x1270' stress-ng: info: [1083] klog-check: warning: [66.447518] ' policy_update+0xe0/0x180' stress-ng: info: [1083] klog-check: warning: [66.447750] ' profile_replace+0xb9/0x150' stress-ng: info: [1083] klog-check: warning: [66.447981] ' vfs_write+0xc8/0x410' stress-ng: info: [1083] klog-check: warning: [66.448213] ' ? kmem_cache_free+0x1e/0x3b0' stress-ng: info: [1083] klog-check: warning: [66.448442] ' ksys_write+0x73/0x100' stress-ng: info: [1083] klog-check: warning: [66.448670] ' __x64_sys_write+0x19/0x30' stress-ng: info: [1083] klog-check: warning: [66.448892] ' do_syscall_64+0x58/0x90' stress-ng: info: [1083] klog-check: warning: [66.449115] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1083] klog-check: warning: [66.449337] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1083] klog-check: warning: [66.449551] ' ? exit_to_user_mode_loop+0xe0/0x130' stress-ng: info: [1083] klog-check: warning: [66.449775] ' ? exit_to_user_mode_prepare+0x30/0xb0' stress-ng: info: [1083] klog-check: warning: [66.449996] ' ? syscall_exit_to_user_mode+0x29/0x50' stress-ng: info: [1083] klog-check: warning: [66.450220] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1083] klog-check: warning: [66.450449] ' ? exit_to_user_mode_prepare+0x30/0xb0' stress-ng: info: [1083] klog-check: warning: [66.450681] ' ? syscall_exit_to_user_mode+0x29/0x50' stress-ng: info: [1083] klog-check: warning: [66.450915] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1083] klog-check: warning: [66.451151] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1083] klog-check: warning: [66.451384] ' entry_SYSCALL_64_after_hwframe+0x72/0xdc' stress-ng: info: [1083] klog-check: warning: [66.451614] 'RIP: 0033:0x7f60f5b0b9e4' stress-ng: info: [1083] klog-check: warning: [66.451848] 'Code: 15 39 a4 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d fd 2b 0f 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48' stress-ng: info: [1083] klog-check: warning: [66.452341] 'RSP: 002b:7ffdaa28bfb8 EFLAGS: 0202 ORIG_RAX: 0001' stress-ng: info:
[Touch-packages] [Bug 2024599] Re: linux-image-5.15.0-1032-realtime locks up under scheduler test load
And with 5.19.0-45-generic: sudo ./stress-ng --apparmor 1 --klog-check [sudo] password for cking: stress-ng: info: [1179] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor stress-ng: info: [1179] dispatching hogs: 1 apparmor stress-ng: info: [1180] klog-check: kernel cmdline: 'BOOT_IMAGE=/vmlinuz-5.19.0-45-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro' stress-ng: error: [1180] klog-check: error: [93.527396] 'AppArmor DFA next/check upper bounds error' stress-ng: error: [1180] klog-check: error: [93.827976] 'AppArmor DFA state with invalid match flags' stress-ng: error: [1180] klog-check: error: [93.991395] 'AppArmor DFA next/check upper bounds error' stress-ng: error: [1180] klog-check: error: [93.992189] 'AppArmor DFA next/check upper bounds error' stress-ng: error: [1180] klog-check: error: [94.007400] 'AppArmor DFA state with invalid match flags' stress-ng: error: [1180] klog-check: error: [94.059345] 'AppArmor DFA state with invalid match flags' stress-ng: error: [1180] klog-check: error: [94.104414] 'AppArmor DFA next/check upper bounds error' stress-ng: error: [1180] klog-check: alert: [94.128617] 'BUG: kernel NULL pointer dereference, address: 0130' stress-ng: error: [1180] klog-check: alert: [94.128644] '#PF: supervisor read access in kernel mode' stress-ng: error: [1180] klog-check: alert: [94.128659] '#PF: error_code(0x) - not-present page' stress-ng: info: [1180] klog-check: warning: [94.128685] 'Oops: [#1] PREEMPT SMP PTI' stress-ng: info: [1180] klog-check: warning: [94.128698] 'CPU: 7 PID: 1185 Comm: stress-ng-appar Not tainted 5.19.0-45-generic #46-Ubuntu' stress-ng: info: [1180] klog-check: warning: [94.128722] 'Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-debian-1.16.0-5 04/01/2014' stress-ng: info: [1180] klog-check: warning: [94.128745] 'RIP: 0010:aa_unpack+0x11f/0x530' stress-ng: info: [1180] klog-check: warning: [94.128762] 'Code: 00 48 85 c0 0f 84 15 04 00 00 48 8d 75 a8 48 8d 7d b0 4c 8b 7d c0 e8 80 ec ff ff 48 89 c3 48 3d 00 f0 ff ff 0f 87 00 02 00 00 <4c> 8b b0 30 01 00 00 4d 85 f6 0f 84 38 01 00 00 49 8b 86 c8 00 00' stress-ng: info: [1180] klog-check: warning: [94.128807] 'RSP: 0018:b1fdc0f57ce0 EFLAGS: 00010207' stress-ng: info: [1180] klog-check: warning: [94.129378] 'RAX: RBX: RCX: ' stress-ng: info: [1180] klog-check: warning: [94.129928] 'RDX: RSI: RDI: ' stress-ng: info: [1180] klog-check: warning: [94.130443] 'RBP: b1fdc0f57d40 R08: R09: ' stress-ng: info: [1180] klog-check: warning: [94.131056] 'R10: R11: R12: b1fdc0f57da8' stress-ng: info: [1180] klog-check: warning: [94.131572] 'R13: b1fdc0f57da0 R14: 9da384835962 R15: 9da384820010' stress-ng: info: [1180] klog-check: warning: [94.132090] 'FS: 7fa65a059740() GS:9da3fbdc() knlGS:' stress-ng: info: [1180] klog-check: warning: [94.132652] 'CS: 0010 DS: ES: CR0: 80050033' stress-ng: info: [1180] klog-check: warning: [94.133206] 'CR2: 0130 CR3: 00010d432006 CR4: 00370ee0' stress-ng: info: [1180] klog-check: warning: [94.133739] 'DR0: DR1: DR2: ' stress-ng: info: [1180] klog-check: warning: [94.134282] 'DR3: DR6: fffe0ff0 DR7: 0400' stress-ng: info: [1180] klog-check: warning: [94.134868] 'Call Trace:' stress-ng: info: [1180] klog-check: warning: [94.135388] ' ' stress-ng: info: [1180] klog-check: warning: [94.135933] ' aa_replace_profiles+0xa1/0x10b0' stress-ng: info: [1180] klog-check: warning: [94.136471] ' ? check_heap_object+0x29/0x1e0' stress-ng: info: [1180] klog-check: warning: [94.137018] ' ? __check_object_size.part.0+0x4c/0xf0' stress-ng: info: [1180] klog-check: warning: [94.137528] ' policy_update+0xd0/0x170' stress-ng: info: [1180] klog-check: warning: [94.138061] ' profile_replace+0xb9/0x150' stress-ng: info: [1180] klog-check: warning: [94.138612] ' vfs_write+0xb7/0x290' stress-ng: info: [1180] klog-check: warning: [94.139124] ' ksys_write+0x73/0x100' stress-ng: info: [1180] klog-check: warning: [94.139616] ' __x64_sys_write+0x19/0x30' stress-ng: info: [1180] klog-check: warning: [94.140104] ' do_syscall_64+0x58/0x90' stress-ng: info: [1180] klog-check: warning: [94.140651] ' ? syscall_exit_to_user_mode+0x29/0x50' stress-ng: info: [1180] klog-check: warning: [94.141130] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1180] klog-check: warning: [94.141630] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1180] klog-check: warning: [94.142117] ' ? do_syscall_64+0x67/0x90' stress-ng: info: [1180] klog-check: warning: [94.142627] ' entry_SYSCALL_64_after_hwframe+0x63/0xcd' stress-ng: info: [1180] klog-check: warning: [94.14309
[Touch-packages] [Bug 2024599] Re: linux-image-5.15.0-1032-realtime locks up under scheduler test load
5.15.0.75 works fine, no problem, 5.19.0-45 kernel crashes, so issue introduced between 5.15 and 5.19 ** Also affects: apparmor (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Low Status: 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/2024599 Title: linux-image-5.15.0-1032-realtime locks up under scheduler test load Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Jammy: New Status in linux source package in Jammy: Incomplete Status in apparmor source package in Kinetic: New Status in linux source package in Kinetic: New Status in apparmor source package in Lunar: New Status in linux source package in Lunar: New Status in apparmor source package in Mantic: New Status in linux source package in Mantic: Incomplete Bug description: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy uname -a Linux jammie-amd64-efi 5.15.0-1032-realtime #35-Ubuntu SMP PREEMPT_RT Tue Jan 24 11:45:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux free totalusedfree shared buff/cache available Mem: 4013888 200984 34390121204 373892 3744628 Swap:4014076 0 4014076 Running in a kvm-qemu, 8 cpus, cpu Intel Core Processor (Skylake, IBRS): how to reproduce issue: git clone https://github.com/ColinIanKing/stress-ng sudo apt-get update sudo apt-get build-dep stress-ng sudo apt-get install libeigen3-dev libmpfr-dev libkmod-dev libxxhash-dev libglvnd-dev libgbm-dev cd stress-ng make clean make -j 8 sudo ./stress-ng --class scheduler --all 1 -v --vmstat 1 -t 30m ..wait for all the stressors to get invoked, system becomes unresponsive, can't ^C stress-ng, can't swap consoles on the VM, appears to be hard locked. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2024599/+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 2024599] Re: linux-image-5.15.0-1032-realtime locks up under scheduler test load
And also occurs in Ubuntu Mantic with 6.3.0-7-generic -- 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/2024599 Title: linux-image-5.15.0-1032-realtime locks up under scheduler test load Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Jammy: New Status in linux source package in Jammy: Incomplete Status in apparmor source package in Kinetic: New Status in linux source package in Kinetic: New Status in apparmor source package in Lunar: New Status in linux source package in Lunar: New Status in apparmor source package in Mantic: New Status in linux source package in Mantic: Incomplete Bug description: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy uname -a Linux jammie-amd64-efi 5.15.0-1032-realtime #35-Ubuntu SMP PREEMPT_RT Tue Jan 24 11:45:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux free totalusedfree shared buff/cache available Mem: 4013888 200984 34390121204 373892 3744628 Swap:4014076 0 4014076 Running in a kvm-qemu, 8 cpus, cpu Intel Core Processor (Skylake, IBRS): how to reproduce issue: git clone https://github.com/ColinIanKing/stress-ng sudo apt-get update sudo apt-get build-dep stress-ng sudo apt-get install libeigen3-dev libmpfr-dev libkmod-dev libxxhash-dev libglvnd-dev libgbm-dev cd stress-ng make clean make -j 8 sudo ./stress-ng --class scheduler --all 1 -v --vmstat 1 -t 30m ..wait for all the stressors to get invoked, system becomes unresponsive, can't ^C stress-ng, can't swap consoles on the VM, appears to be hard locked. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2024599/+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 2024599] Re: linux-image-5.15.0-1032-realtime locks up under scheduler test load
Thanks JJ, much appreciated :-) -- 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/2024599 Title: linux-image-5.15.0-1032-realtime locks up under scheduler test load Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Jammy: New Status in linux source package in Jammy: Incomplete Status in apparmor source package in Kinetic: New Status in linux source package in Kinetic: New Status in apparmor source package in Lunar: New Status in linux source package in Lunar: New Status in apparmor source package in Mantic: New Status in linux source package in Mantic: Incomplete Bug description: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy uname -a Linux jammie-amd64-efi 5.15.0-1032-realtime #35-Ubuntu SMP PREEMPT_RT Tue Jan 24 11:45:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux free totalusedfree shared buff/cache available Mem: 4013888 200984 34390121204 373892 3744628 Swap:4014076 0 4014076 Running in a kvm-qemu, 8 cpus, cpu Intel Core Processor (Skylake, IBRS): how to reproduce issue: git clone https://github.com/ColinIanKing/stress-ng sudo apt-get update sudo apt-get build-dep stress-ng sudo apt-get install libeigen3-dev libmpfr-dev libkmod-dev libxxhash-dev libglvnd-dev libgbm-dev cd stress-ng make clean make -j 8 sudo ./stress-ng --class scheduler --all 1 -v --vmstat 1 -t 30m ..wait for all the stressors to get invoked, system becomes unresponsive, can't ^C stress-ng, can't swap consoles on the VM, appears to be hard locked. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2024599/+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 1615641] Re: initramfs waits for 5 seconds when executing /scripts/local-premount/resume
We may as well close this issue, I don't have that laptop any more, I don't work for Canonical any more and the boot speed regressions seem to have fallen off the CTO's "must do priority radar" otherwise this kind of regression would have had more engineering time devoted to it. -- 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/1615641 Title: initramfs waits for 5 seconds when executing /scripts/local- premount/resume Status in initramfs-tools package in Ubuntu: Incomplete Bug description: I've noticed that boots on Ubuntu Yakkety have slowed down recently. I added some debug into my kernel to see where delays are occurring and I can observe 5 seconds being consumed in /scripts/local- premount/resume : Aug 22 14:34:36 lenovo kernel: [6.823263] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.82] do_exec: 824 (init) /scripts/local-premount/ntfs_3g Aug 22 14:34:36 lenovo kernel: [6.823766] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.823845] do_exec: 825 (init) /scripts/local-premount/resume Aug 22 14:34:36 lenovo kernel: [6.824214] _do_fork: 825 (resume) Aug 22 14:34:36 lenovo kernel: [6.824322] do_exec: 826 (resume) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.825642] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [ 11.825800] do_exec: 827 (init) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.826691] _do_fork: 1 (init) It seems that /scripts/local-premount/resume is being called and wait- for-root times out after 5 seconds. The resume script does set a 5 second timeout, so I must be hitting that for some reason. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1615641/+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 1438301] [NEW] desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart
Public bug reported: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. ** Affects: systemd (Ubuntu) Importance: Critical Status: New ** Attachment added: "gzip'd syslog" https://bugs.launchpad.net/bugs/1438301/+attachment/4361129/+files/syslog.gz ** Summary changed: - desktop machine suspends after ~3 minutes, does suspend with upstart + desktop machine suspends after ~3 minutes, does NOT suspend with upstart ** Summary changed: - desktop machine suspends after ~3 minutes, does NOT suspend with upstart + desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart ** Description changed: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot - with upstart it does not. + with upstart it does not. This happens everytime I boot with systemd, + the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. - $ acpi_listen + $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. -- 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/1438301 Title: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart Status in systemd package in Ubuntu: New Bug description: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+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 1438301] Re: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart
** Changed in: systemd (Ubuntu) Importance: Undecided => Critical -- 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/1438301 Title: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart Status in systemd package in Ubuntu: New Bug description: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+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 1438301] Re: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart
journalctl -f -b -u systemd-logind -- Logs begin at Tue 2015-03-31 09:36:25 BST. -- Mar 31 09:36:26 skylake systemd[1]: Starting Login Service... Mar 31 09:36:26 skylake systemd-logind[671]: New seat seat0. Mar 31 09:36:26 skylake systemd-logind[671]: Watching system buttons on /dev/input/event3 (Power Button) Mar 31 09:36:26 skylake systemd-logind[671]: Watching system buttons on /dev/input/event0 (Lid Switch) Mar 31 09:36:26 skylake systemd-logind[671]: Watching system buttons on /dev/input/event1 (Power Button) Mar 31 09:36:26 skylake systemd-logind[671]: Watching system buttons on /dev/input/event2 (Sleep Button) Mar 31 09:36:26 skylake systemd[1]: Started Login Service. Mar 31 09:36:32 skylake systemd-logind[671]: New session 1 of user king. Mar 31 09:39:22 skylake systemd-logind[671]: Suspending... -- 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/1438301 Title: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart Status in systemd package in Ubuntu: Incomplete Bug description: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+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 1438301] Re: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart
The HandleLidSwitch=ignore stops the box from suspending: $ uptime 09:50:25 up 5 min, 2 users, load average: 0.00, 0.00, 0.00 -- 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/1438301 Title: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart Status in systemd package in Ubuntu: Incomplete Bug description: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+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 1438301] Re: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart
I'm actually running vivid server on this box, so I don't have a unity session running. -- 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/1438301 Title: desktop machine suspends with systemd after ~3 minutes, does NOT suspend with upstart Status in systemd package in Ubuntu: Incomplete Bug description: For reasons I cannot fathom, my development server goes into deep suspend after ~3 minutes after startup with systemd, however, if I boot with upstart it does not. This happens everytime I boot with systemd, the machine just goes into a deep suspend without me requesting it. I enabled "debug"; attached is a gzip'd syslog showing the activity - look at the end of the log, it goes into deep suspend. No idea why. acpi_listen is showing some curious audio plug/unplug events that seem to occur on this development box, so maybe these are being misinterpreted as suspend events. $ acpi_listen jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug jack/headphone HEADPHONE plug jack/headphone HEADPHONE unplug ..but I am not seeing any other ACPI related events that could be triggering a suspend request from acpi_listen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+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 1433720] [NEW] shutdown request timeouts out and leaves tty in non-echo mode
Public bug reported: I believe this is a change in shutdown tied somehow to systemd, but I am guessing. How to reproduce the bug: sudo shutdown -h now [ wait a couple of minutes, don't enter in one's password ] authentication times out and one is left with non-echo on one's tty. This has to be restored back to normal using tset. It's annoying and a regression on the old way shutdown worked. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-4ubuntu5 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Mar 18 17:56:52 2015 EcryptfsInUse: Yes InstallationDate: Installed on 2014-06-05 (286 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520) MachineType: LENOVO 2320CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-9-generic root=UUID=8f6baa39-b057-41c2-bfe9-6c77484299ab ro quiet splash pcie_aspm=force crashkernel=384M-:128M vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/24/2012 dmi.bios.vendor: LENOVO dmi.bios.version: G2ET31WW (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 2320CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG2ET31WW(1.11):bd05/24/2012:svnLENOVO:pn2320CTO:pvrThinkPadX230:rvnLENOVO:rn2320CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2320CTO dmi.product.version: ThinkPad X230 dmi.sys.vendor: LENOVO ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug vivid -- 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/1433720 Title: shutdown request timeouts out and leaves tty in non-echo mode Status in systemd package in Ubuntu: New Bug description: I believe this is a change in shutdown tied somehow to systemd, but I am guessing. How to reproduce the bug: sudo shutdown -h now [ wait a couple of minutes, don't enter in one's password ] authentication times out and one is left with non-echo on one's tty. This has to be restored back to normal using tset. It's annoying and a regression on the old way shutdown worked. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-4ubuntu5 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Mar 18 17:56:52 2015 EcryptfsInUse: Yes InstallationDate: Installed on 2014-06-05 (286 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520) MachineType: LENOVO 2320CTO ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-9-generic root=UUID=8f6baa39-b057-41c2-bfe9-6c77484299ab ro quiet splash pcie_aspm=force crashkernel=384M-:128M vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/24/2012 dmi.bios.vendor: LENOVO dmi.bios.version: G2ET31WW (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 2320CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG2ET31WW(1.11):bd05/24/2012:svnLENOVO:pn2320CTO:pvrThinkPadX230:rvnLENOVO:rn2320CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2320CTO dmi.product.version: ThinkPad X230 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1433720/+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 1470845] [NEW] systemd on wily desktop generating short lived threads every second in a quiet system
Public bug reported:
I noticed that systemd on my idle Wily desktop is creating very short
lived threads at 1Hz. While these aren't doing much, it still consumes
power doing wakeups to create these periodic threads.
Showing thread creation with forkstat:
$ sudo forkstat
Time Event PID Info Duration Process
13:43:07 clone 1 parent /sbin/init splash
13:43:07 clone 7483 thread /sbin/init splash
13:43:07 exit 7483 00.001 /sbin/init splash
13:43:08 clone 1 parent /sbin/init splash
13:43:08 clone 7484 thread /sbin/init splash
13:43:08 exit 7484 00.000 /sbin/init splash
13:43:10 clone 1 parent /sbin/init splash
13:43:10 clone 7485 thread /sbin/init splash
13:43:10 exit 7485 00.000 /sbin/init splash
13:43:11 clone 1 parent /sbin/init splash
13:43:11 clone 7486 thread /sbin/init splash
13:43:11 exit 7486 00.000 /sbin/init splash
13:43:12 clone 1 parent /sbin/init splash
13:43:12 clone 7487 thread /sbin/init splash
13:43:12 exit 7487 00.000 /sbin/init splash
13:43:13 clone 1 parent /sbin/init splash
13:43:13 clone 7488 thread /sbin/init splash
13:43:13 exit 7488 00.000 /sbin/init splash
13:43:15 clone 1 parent /sbin/init splash
13:43:15 clone 7489 thread /sbin/init splash
13:43:15 exit 7489 00.000 /sbin/init splash
13:43:16 clone 1 parent /sbin/init splash
13:43:16 clone 7490 thread /sbin/init splash
13:43:16 exit 7490 00.000 /sbin/init splash
13:43:17 clone 1 parent /sbin/init splash
13:43:17 clone 7491 thread /sbin/init splash
13:43:17 exit 7491 00.000 /sbin/init splash
And it's consuming some cycles over time:
$ sudo perf stat -p 1
^C
Performance counter stats for process id '1':
7.519868 task-clock (msec) #0.000 CPUs utilized
41 context-switches #0.005 M/sec
39 cpu-migrations#0.005 M/sec
3 page-faults #0.399 K/sec
12,107,977 cycles#1.610 GHz
10,597,101 stalled-cycles-frontend # 87.52% frontend cycles
idle
0 stalled-cycles-backend#0.00% backend cycles
idle
2,285,818 instructions #0.19 insns per cycle
#4.64 stalled cycles per
insn
457,133 branches # 60.790 M/sec
69,444 branch-misses # 15.19% of all branches
46.099593011 seconds time elapsed
The thread is just doing the following:
clock_gettime(0x7 /* CLOCK_??? */, {52592, 947682919}) = 0
read(14, "\1\0\0\0\0\0\0\0", 8) = 8
fcntl(30, F_DUPFD_CLOEXEC, 3) = 15
ioctl(30, 0xc0189374, 0x7ffeaf311470) = 0
fcntl(16, F_GETFD) = 0x1 (flags FD_CLOEXEC)
clone(Process 7466 attached
child_stack=0x7f97c3580e30,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f97c35819d0, tls=0x7f97c3581700, child_tidptr=0x7f97c35819d0)
= 7466
[pid 7466] set_robust_list(0x7f97c35819e0, 24) = 0
[pid 1] timerfd_settime(14, TFD_TIMER_ABSTIME, {it_interval={0, 0},
it_value={52594, 197493000}}, NULL
[pid 7466] ioctl(15, 0xc018937c
[pid 1] <... timerfd_settime resumed> ) = 0
[pid 7466] <... ioctl resumed> , 0x7f97c3580d60) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 1] epoll_wait(4,
[pid 7466] close(15) = 0
[pid 7466] close(16) = 0
[pid 7466] madvise(0x7f97c2d81000, 8368128, MADV_DONTNEED) = 0
[pid 7466] _exit(0)= ?
[pid 7466] +++ exited with 0 +++
<... epoll_wait resumed> {{EPOLLIN, {u32=3, u64=3}}}, 34, -1) = 1
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- systemd on wily desktop generating short lived threads every second in a
quite system
+ systemd on wily desktop generating short lived threads every second in a
quiet system
--
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/1470845
Title:
systemd on wily desktop generating short lived threads every second in
a quiet system
Status in systemd package in Ubuntu:
New
Bug description:
I noticed that systemd on my idle Wily desktop is creating very short
lived threads at 1Hz. While these aren't doing much, it still
consumes power doing wakeups to create these periodic threads.
Showing thread creation wi
[Touch-packages] [Bug 1466273] Re: gstreamer fails intermittently
It may be that the process is swapped out, so the delivery of the SIGKILL takes a while for it to be swapped back in and to hence get the signal. To test this hypothesis: a) one could disable swap and see if the process can be delivered the SIGKILL and how quickly it responds to that. However, turning swap off may cause the OOM killer to change the way things behave and hence is not a viable test pattern. b) run smemstat (from ppa:colin-king/white) and see how much memory of the given blocked process is swapped out compared to the memory resident. If it is mostly swapped out, it could indicate why it is taken a while to get swapped back in and to respond to the SIGKILL. c) one could add a mlockall() to the slow responding process or even mlock() on the range of text pages that handle the signal and do the ppoll so it's not swapped out. Note that one needs to allow the process to have the CAP_IPC_LOCK capability or one could tweak the RLIMIT_MEMLOCK soft limit using ulimit -l -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gstreamer1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1466273 Title: gstreamer fails intermittently Status in Thumbnail generator for all kinds of files: New Status in gstreamer1.0 package in Ubuntu: New Bug description: gstreamer occasionally fails to extract a thumbnail from a video file. It's clearly a race condition because, almost all of the time, it succeeds. To reproduce: Check out the thumbnailer/devel branch at r217 and build it. Then: cd build/src/vs-thumb ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg Point a browser at the generated x.jpg file and check that the image was extracted correctly. Now run while ./vs-thumb fd://0 ./x.jpg <../../../tests/media/testvideo.ogg ; do :; done Within maybe a hundred iterations or so, I get: Error creating thumbnail: ThumbnailExtractor: change_state(): reading async messages: GStreamer error: negotiation problem. To manage notifications about this bug go to: https://bugs.launchpad.net/thumbnailer/+bug/1466273/+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 1470845] Re: systemd on wily desktop generating short lived threads every second in a quiet system
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
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/1470845
Title:
systemd on wily desktop generating short lived threads every second in
a quiet system
Status in systemd package in Ubuntu:
New
Bug description:
I noticed that systemd on my idle Wily desktop is creating very short
lived threads at 1Hz. While these aren't doing much, it still
consumes power doing wakeups to create these periodic threads.
Showing thread creation with forkstat:
$ sudo forkstat
Time Event PID Info Duration Process
13:43:07 clone 1 parent /sbin/init splash
13:43:07 clone 7483 thread /sbin/init splash
13:43:07 exit 7483 00.001 /sbin/init splash
13:43:08 clone 1 parent /sbin/init splash
13:43:08 clone 7484 thread /sbin/init splash
13:43:08 exit 7484 00.000 /sbin/init splash
13:43:10 clone 1 parent /sbin/init splash
13:43:10 clone 7485 thread /sbin/init splash
13:43:10 exit 7485 00.000 /sbin/init splash
13:43:11 clone 1 parent /sbin/init splash
13:43:11 clone 7486 thread /sbin/init splash
13:43:11 exit 7486 00.000 /sbin/init splash
13:43:12 clone 1 parent /sbin/init splash
13:43:12 clone 7487 thread /sbin/init splash
13:43:12 exit 7487 00.000 /sbin/init splash
13:43:13 clone 1 parent /sbin/init splash
13:43:13 clone 7488 thread /sbin/init splash
13:43:13 exit 7488 00.000 /sbin/init splash
13:43:15 clone 1 parent /sbin/init splash
13:43:15 clone 7489 thread /sbin/init splash
13:43:15 exit 7489 00.000 /sbin/init splash
13:43:16 clone 1 parent /sbin/init splash
13:43:16 clone 7490 thread /sbin/init splash
13:43:16 exit 7490 00.000 /sbin/init splash
13:43:17 clone 1 parent /sbin/init splash
13:43:17 clone 7491 thread /sbin/init splash
13:43:17 exit 7491 00.000 /sbin/init splash
And it's consuming some cycles over time:
$ sudo perf stat -p 1
^C
Performance counter stats for process id '1':
7.519868 task-clock (msec) #0.000 CPUs utilized
41 context-switches #0.005 M/sec
39 cpu-migrations#0.005 M/sec
3 page-faults #0.399 K/sec
12,107,977 cycles#1.610 GHz
10,597,101 stalled-cycles-frontend # 87.52% frontend cycles
idle
0 stalled-cycles-backend#0.00% backend cycles
idle
2,285,818 instructions #0.19 insns per cycle
#4.64 stalled cycles
per insn
457,133 branches # 60.790 M/sec
69,444 branch-misses # 15.19% of all branches
46.099593011 seconds time elapsed
The thread is just doing the following:
clock_gettime(0x7 /* CLOCK_??? */, {52592, 947682919}) = 0
read(14, "\1\0\0\0\0\0\0\0", 8) = 8
fcntl(30, F_DUPFD_CLOEXEC, 3) = 15
ioctl(30, 0xc0189374, 0x7ffeaf311470) = 0
fcntl(16, F_GETFD) = 0x1 (flags FD_CLOEXEC)
clone(Process 7466 attached
child_stack=0x7f97c3580e30,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f97c35819d0, tls=0x7f97c3581700, child_tidptr=0x7f97c35819d0)
= 7466
[pid 7466] set_robust_list(0x7f97c35819e0, 24) = 0
[pid 1] timerfd_settime(14, TFD_TIMER_ABSTIME, {it_interval={0, 0},
it_value={52594, 197493000}}, NULL
[pid 7466] ioctl(15, 0xc018937c
[pid 1] <... timerfd_settime resumed> ) = 0
[pid 7466] <... ioctl resumed> , 0x7f97c3580d60) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 1] epoll_wait(4,
[pid 7466] close(15) = 0
[pid 7466] close(16) = 0
[pid 7466] madvise(0x7f97c2d81000, 8368128, MADV_DONTNEED) = 0
[pid 7466] _exit(0)= ?
[pid 7466] +++ exited with 0 +++
<... epoll_wait resumed> {{EPOLLIN, {u32=3, u64=3}}}, 34, -1) = 1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1470845/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe :
[Touch-packages] [Bug 1471906] Re: camera app is polling the file system every second
OK, I guess that is the cost of a high level API that doesn't use statfs(). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to camera-app in Ubuntu. https://bugs.launchpad.net/bugs/1471906 Title: camera app is polling the file system every second Status in camera-app: Confirmed Status in Canonical System Image: Confirmed Status in camera-app package in Ubuntu: Confirmed Bug description: from OEM bug #1471310 running fnotifystat, I can see that every second the camera-app is polling away as follows: Total Open Close Read Write PID Process Pathname 8.0 1.0 1.0 6.0 0.0 3175 camera-app /proc/3175/mounts 2.0 1.0 1.0 0.0 0.0 3175 camera-app /dev/disk/by-label Total Open Close Read Write PID Process Pathname 8.0 1.0 1.0 6.0 0.0 3175 camera-app /proc/3175/mounts 2.0 1.0 1.0 0.0 0.0 3175 camera-app /dev/disk/by-label Total Open Close Read Write PID Process Pathname 8.0 1.0 1.0 6.0 0.0 3175 camera-app /proc/3175/mounts 2.0 1.0 1.0 0.0 0.0 3175 camera-app /dev/disk/by-label so it is consistently polling away. That's kinda wasteful on resources (e.g. battery drain). To manage notifications about this bug go to: https://bugs.launchpad.net/camera-app/+bug/1471906/+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 1471029] Re: ELF programs with R_386_RELATIVE blocks are badly mapped into memory
Commit a87938b2e was included in 3.19.0-20.20 (see commit b51621abbcb4694b8d2842ce3a66006a60bba6e5), so perhaps trying this would be the first step to see if that commit fixes things. As it stands, I've checked the heap and stack on a VM image using this kernel and there is now plenty of space for the stack and heap. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxslt in Ubuntu. https://bugs.launchpad.net/bugs/1471029 Title: ELF programs with R_386_RELATIVE blocks are badly mapped into memory Status in libxslt package in Ubuntu: Triaged Status in linux package in Ubuntu: Triaged Bug description: Running the Samba autobuild tests on a 15.04 openstack image results in a segfault in this command: /usr/bin/xsltproc --nonet -o default/docs-xml/manpages/smb.conf.5 /home/ubuntu/autobuild/b22271/samba/docs-xml/xslt/man.xsl default /docs-xml/manpages/smb.conf.5.xml I reported this upstream as a bug in xsltproc, but it was found to be impossible to reproduce using upstream source on the openstack instance: https://bugzilla.gnome.org/show_bug.cgi?id=751764 Comment 8 (https://bugzilla.gnome.org/show_bug.cgi?id=751764#c8) is particularly informative. The stack trace below shows the segfault actually occurs in libxml's xpath evaluation functions. I see no difference between xpath.c in upstream 2.9.2 and Ubuntu's version. (gdb) bt 12 #0 0xb760f874 in xmlXPathCompOpEval (ctxt=0xba25d3e8, op=0xb86bc818) at ../../xpath.c:13606 #1 0xb760f82e in xmlXPathCompOpEval (ctxt=0xba25d3e8, op=0xb86bc890) at ../../xpath.c:13598 #2 0xb7610244 in xmlXPathCompOpEval (ctxt=0xba25d3e8, op=0xb86bc8b8) at ../../xpath.c:13529 #3 0xb760f9d6 in xmlXPathCompOpEval (ctxt=0xba25d3e8, op=0xb86bc8e0) at ../../xpath.c:13977 #4 0xb7612735 in xmlXPathCompOpEval (op=, ctxt=0xba25d3e8) at ../../xpath.c:14552 #5 xmlXPathRunEval (ctxt=0xba25d3e8, toBool=) at ../../xpath.c:14552 #6 0xb76171ed in xmlXPathCompiledEvalInternal (toBool=0, resObj=, ctxt=, comp=) at ../../xpath.c:14915 #7 xmlXPathCompiledEval__internal_alias (comp=0xb866a948, ctx=0xb99bd308) at ../../xpath.c:14978 #8 0xb7787260 in xsltEvalVariable (ctxt=ctxt@entry=0xb9836560, variable=variable@entry=0xba25d3b0, castedComp=0xb86a4238) at ../../../libxslt/variables.c:903 #9 0xb778759a in xsltBuildVariable (ctxt=0xb9836560, castedComp=0xb86a4238, tree=0xb86a6978) at ../../../libxslt/variables.c:1759 #10 0xb7788bfa in xsltParseStylesheetCallerParam (ctxt=0xb86a6978, inst=0xb86a6978) at ../../../libxslt/variables.c:1975 #11 0xb779b9db in xsltCallTemplate (ctxt=0xb9836560, node=0xb85efed8, inst=0xb86a6880, castedComp=0xb86a4148) at ../../../libxslt/transform.c:4739 (More stack frames follow...) (gdb) bt -5 #3311 0xb779a7de in xsltProcessOneNode (ctxt=0xb9836560, contextNode=0xb97586a0, withParams=0x0) at ../../../libxslt/transform.c:2097 #3312 0xb779d818 in xsltApplyStylesheetInternal (style=0xba25d3e8, style@entry=0xb85ee200, doc=0xb86bc7f0, doc@entry=0xb97586a0, params=0xb77ed340 , output=0xb85e13e0 "default/docs-xml/manpages/smb.conf.5", profile=0x0, userCtxt=0xb9836560) at ../../../libxslt/transform.c:6159 #3313 0xb779df8d in xsltRunStylesheetUser (style=0xb85ee200, doc=0xb97586a0, params=0xb77ed340 , output=0xb85e13e0 "default/docs-xml/manpages/smb.conf.5", SAX=0x0, IObuf=0x0, profile=0x0, userCtxt=0xb9836560) at ../../../libxslt/transform.c:6449 #3314 0xb77ea12c in xsltProcess (doc=0xb97586a0, cur=0xb85ee200, filename=0xbfd59812 "default/docs-xml/manpages/smb.conf.5.xml") at ../../../xsltproc/xsltproc.c:483 #3315 0xb77e9298 in main (argc=6, argv=0xbfd58f94) at ../../../xsltproc/xsltproc.c:903 --- AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jul 9 00:13 seq crw-rw 1 root audio 116, 33 Jul 9 00:13 timer AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.17.2-0ubuntu1.1 Architecture: i386 ArecordDevices: Error: [Errno 2] No such file or directory AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/timer', '/dev/snd/seq'] failed with exit code 1: CRDA: Error: [Errno 2] No such file or directory DistroRelease: Ubuntu 15.04 Ec2AMI: ami-012b Ec2AMIManifest: FIXME Ec2AvailabilityZone: nz-por-1a Ec2InstanceType: c1.c4r4 Ec2Kernel: aki-0005 Ec2Ramdisk: ari-0005 IwConfig: Error: [Errno 2] No such file or directory Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: OpenStack Foundation OpenStack Nova Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-20-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 ProcV
[Touch-packages] [Bug 1350871] [NEW] location service is waking up at 10Hz causing possible unwanted wakeups
Public bug reported: I've observed that location service is waking up ~10 times per second due to a 100ms sleep ps -ax | grep 2295 2295 ?Ssl0:00 /usr/bin/ubuntu-location-serviced --bus system --provider gps::Provider eventstat shows it's the top waking userspace process on the phone: root@ubuntu-phablet:/# eventstat 300 1 Event/s PID TaskInit Function Callback 9.99 2304 ubuntu-location hrtimer_start_range_nshrtimer_wakeup health-check shows that this is occuring in a 100ms nanosleep() system call. Attached is the output from health-check. Is is possible to use a select() or poll() rather than a 10Hz non-blocking delay loop to reduce polling wakeups? ** Affects: location-service (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Output of health-check showing polled 10Hz sleep issue" https://bugs.launchpad.net/bugs/1350871/+attachment/4166674/+files/health-check.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to location-service in Ubuntu. https://bugs.launchpad.net/bugs/1350871 Title: location service is waking up at 10Hz causing possible unwanted wakeups Status in “location-service” package in Ubuntu: New Bug description: I've observed that location service is waking up ~10 times per second due to a 100ms sleep ps -ax | grep 2295 2295 ?Ssl0:00 /usr/bin/ubuntu-location-serviced --bus system --provider gps::Provider eventstat shows it's the top waking userspace process on the phone: root@ubuntu-phablet:/# eventstat 300 1 Event/s PID TaskInit Function Callback 9.99 2304 ubuntu-location hrtimer_start_range_nshrtimer_wakeup health-check shows that this is occuring in a 100ms nanosleep() system call. Attached is the output from health-check. Is is possible to use a select() or poll() rather than a 10Hz non-blocking delay loop to reduce polling wakeups? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1350871/+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 1350871] Re: location service is waking up at 10Hz causing possible unwanted wakeups
** Changed in: location-service (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to location-service in Ubuntu. https://bugs.launchpad.net/bugs/1350871 Title: location service is waking up at 10Hz causing possible unwanted wakeups Status in “location-service” package in Ubuntu: New Bug description: I've observed that location service is waking up ~10 times per second due to a 100ms sleep ps -ax | grep 2295 2295 ?Ssl0:00 /usr/bin/ubuntu-location-serviced --bus system --provider gps::Provider eventstat shows it's the top waking userspace process on the phone: root@ubuntu-phablet:/# eventstat 300 1 Event/s PID TaskInit Function Callback 9.99 2304 ubuntu-location hrtimer_start_range_nshrtimer_wakeup health-check shows that this is occuring in a 100ms nanosleep() system call. Attached is the output from health-check. Is is possible to use a select() or poll() rather than a 10Hz non-blocking delay loop to reduce polling wakeups? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1350871/+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 1661030] [NEW] regession tests failing after stackprofile test is run
Public bug reported: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flags running setattr running symlink running syscall running tcp running unix_fd_server running unix_socket_pathname xpass: AF_UNIX pathname socket (dgram); confined server w/ access (rw) xpass: AF_UNIX pathname socket (dgram); confined client w/ access (rw) running unix_socket_abstract running unix_socket_unnamed xpass: AF_UNIX unnamed socket (dgram); confined server (peer label w/ implicit perms) xpass: AF_UNIX unnamed socket (dgram); confined server (peer label w/ explicit perms) xpass: AF_UNIX unnamed socket (dgram); confined server (peer label, peer addr) xpass: AF_UNIX unnamed socket (dgram); confined server (type, peer label, peer addr) xpass: AF_UNIX unnamed socket (dgram); confined server (type, addr, peer label) xpass: AF_UNIX unnamed socket (dgram); confined server (type, addr, peer label, peer addr) running unlink running xattrs Required feature 'file/xattr' not available.. Skipping tests ... running longpath running dbus_eavesdrop running dbus_message running dbus_service running dbus_unrequested_reply running aa_policy_cache running
[Touch-packages] [Bug 1661030] Re: regession tests failing after stackprofile test is run
4.9.0-12_4.9.0-12.13 + jj latest fixes that landed on the kernel-team mailing list in the last 24 hours. -- 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/1661030 Title: regession tests failing after stackprofile test is run Status in apparmor package in Ubuntu: Incomplete Bug description: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flags running setattr running symlink running syscall running tcp running unix_fd_server running unix_socket_pathname xpass: AF_UNIX pathname socket (dgram); confined server w/ access (rw) xpass: AF_UNIX pathname socket (dgram); confined client w/ access (rw) running unix_socket_abstract running unix_socket_unnamed xpass: AF_UNIX unnamed socket (dgram); confined server (peer label w/ implicit perms) xpass: AF_UNIX unnamed socket (dgram); confine
[Touch-packages] [Bug 1661030] Re: regession tests failing after stackprofile test is run
tested and verified it is fixed on Ubuntu Yakkety with -proposed kernel 4.8.0-39-generic #42 ** Tags removed: verification-needed-yakkety ** Tags added: verification-done-yakkety -- 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/1661030 Title: regession tests failing after stackprofile test is run Status in apparmor package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in apparmor source package in Zesty: Fix Released Status in linux source package in Zesty: Incomplete Bug description: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flag
[Touch-packages] [Bug 1661030] Re: regession tests failing after stackprofile test is run
tested and verified it is fixed on Ubuntu Xenial with -proposed kernel 4.4.0-64 #86 ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- 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/1661030 Title: regession tests failing after stackprofile test is run Status in apparmor package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in apparmor source package in Zesty: Fix Released Status in linux source package in Zesty: Incomplete Bug description: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flags runnin
[Touch-packages] [Bug 1696970] [NEW] softlockup DoS causes systemd-journald.service to abort with SIGABORT
Public bug reported: I was running the new stress-ng softlockup stressor and observed that systemd-journald gets killed with an abort and this corrupts the systemd journal. How to reproduce: git clone git://kernel.ubuntu.com/cking/stress-ng cd stress-ng make clean; make sudo ./stress-ng --softlockup 0 -t 360 -v ..and wait for 360 seconds. dmesg shows the following, 100% reproduceable: [ 875.310331] systemd[1]: systemd-timesyncd.service: Watchdog timeout (limit 3min)! [ 875.310740] systemd[1]: systemd-timesyncd.service: Killing process 574 (systemd-timesyn) with signal SIGABRT. [ 875.327289] systemd[1]: systemd-timesyncd.service: Main process exited, code=killed, status=6/ABRT [ 875.327666] systemd[1]: systemd-timesyncd.service: Unit entered failed state. [ 875.327686] systemd[1]: systemd-timesyncd.service: Failed with result 'watchdog'. [ 875.327917] systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. [ 875.327954] systemd[1]: Stopped Network Time Synchronization. [ 875.328845] systemd[1]: Starting Network Time Synchronization... [ 875.525071] systemd[1]: Started Network Time Synchronization. [ 875.539619] systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=6/ABRT [ 875.544257] systemd-journald[5214]: File /run/log/journal/440e485e550040e3b93b66b2faae8525/system.journal corrupted or uncleanly shut down, renaming and replacing. ** Affects: systemd (Ubuntu) Importance: High Status: New ** Changed in: systemd (Ubuntu) Importance: Undecided => High -- 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/1696970 Title: softlockup DoS causes systemd-journald.service to abort with SIGABORT Status in systemd package in Ubuntu: New Bug description: I was running the new stress-ng softlockup stressor and observed that systemd-journald gets killed with an abort and this corrupts the systemd journal. How to reproduce: git clone git://kernel.ubuntu.com/cking/stress-ng cd stress-ng make clean; make sudo ./stress-ng --softlockup 0 -t 360 -v ..and wait for 360 seconds. dmesg shows the following, 100% reproduceable: [ 875.310331] systemd[1]: systemd-timesyncd.service: Watchdog timeout (limit 3min)! [ 875.310740] systemd[1]: systemd-timesyncd.service: Killing process 574 (systemd-timesyn) with signal SIGABRT. [ 875.327289] systemd[1]: systemd-timesyncd.service: Main process exited, code=killed, status=6/ABRT [ 875.327666] systemd[1]: systemd-timesyncd.service: Unit entered failed state. [ 875.327686] systemd[1]: systemd-timesyncd.service: Failed with result 'watchdog'. [ 875.327917] systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. [ 875.327954] systemd[1]: Stopped Network Time Synchronization. [ 875.328845] systemd[1]: Starting Network Time Synchronization... [ 875.525071] systemd[1]: Started Network Time Synchronization. [ 875.539619] systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=6/ABRT [ 875.544257] systemd-journald[5214]: File /run/log/journal/440e485e550040e3b93b66b2faae8525/system.journal corrupted or uncleanly shut down, renaming and replacing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1696970/+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 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
I think this is a systemd/udevd kinda bug isn't it? ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Importance: Undecided => High -- 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/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2659 child /lib/systemd/systemd-udevd 16:35:
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
OK, a bit more data: Xenial with 4.4 and 4.8 kernels - works fine (so not a 4.8 kernel regression) Yakkety with 4.4 and 4.8 kernels - shows the slow behavior (so not a kernel issue) So I think this is a problem in the plumbing layer. ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) ** Tags removed: kernel-4.8 -- 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/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/s
[Touch-packages] [Bug 1615641] [NEW] initramfs waits for 5 seconds when executing /scripts/local-premount/resume
Public bug reported: I've noticed that boots on Ubuntu Yakkety have slowed down recently. I added some debug into my kernel to see where delays are occurring and I can observe 5 seconds being consumed in /scripts/local-premount/resume : Aug 22 14:34:36 lenovo kernel: [6.823263] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.82] do_exec: 824 (init) /scripts/local-premount/ntfs_3g Aug 22 14:34:36 lenovo kernel: [6.823766] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.823845] do_exec: 825 (init) /scripts/local-premount/resume Aug 22 14:34:36 lenovo kernel: [6.824214] _do_fork: 825 (resume) Aug 22 14:34:36 lenovo kernel: [6.824322] do_exec: 826 (resume) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.825642] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [ 11.825800] do_exec: 827 (init) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.826691] _do_fork: 1 (init) It seems that /scripts/local-premount/resume is being called and wait- for-root times out after 5 seconds. The resume script does set a 5 second timeout, so I must be hitting that for some reason. ** Affects: initramfs-tools (Ubuntu) Importance: High Status: New ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => High ** Description changed: I've noticed that boots on Ubuntu Yakkety have slowed down recently. I added some debug into my kernel to see where delays are occurring and I - can observed 5 seconds being consumed in /scripts/local-premount/resume + can observe 5 seconds being consumed in /scripts/local-premount/resume : Aug 22 14:34:36 lenovo kernel: [6.823263] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.82] do_exec: 824 (init) /scripts/local-premount/ntfs_3g Aug 22 14:34:36 lenovo kernel: [6.823766] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.823845] do_exec: 825 (init) /scripts/local-premount/resume Aug 22 14:34:36 lenovo kernel: [6.824214] _do_fork: 825 (resume) Aug 22 14:34:36 lenovo kernel: [6.824322] do_exec: 826 (resume) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.825642] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [ 11.825800] do_exec: 827 (init) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.826691] _do_fork: 1 (init) It seems that /scripts/local-premount/resume is being called and wait- for-root times out after 5 seconds. The resume script does set a 5 second timeout, so I must be hitting that for some reason. -- 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/1615641 Title: initramfs waits for 5 seconds when executing /scripts/local- premount/resume Status in initramfs-tools package in Ubuntu: New Bug description: I've noticed that boots on Ubuntu Yakkety have slowed down recently. I added some debug into my kernel to see where delays are occurring and I can observe 5 seconds being consumed in /scripts/local- premount/resume : Aug 22 14:34:36 lenovo kernel: [6.823263] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.82] do_exec: 824 (init) /scripts/local-premount/ntfs_3g Aug 22 14:34:36 lenovo kernel: [6.823766] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [6.823845] do_exec: 825 (init) /scripts/local-premount/resume Aug 22 14:34:36 lenovo kernel: [6.824214] _do_fork: 825 (resume) Aug 22 14:34:36 lenovo kernel: [6.824322] do_exec: 826 (resume) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.825642] _do_fork: 1 (init) Aug 22 14:34:36 lenovo kernel: [ 11.825800] do_exec: 827 (init) /sbin/wait-for-root Aug 22 14:34:36 lenovo kernel: [ 11.826691] _do_fork: 1 (init) It seems that /scripts/local-premount/resume is being called and wait- for-root times out after 5 seconds. The resume script does set a 5 second timeout, so I must be hitting that for some reason. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1615641/+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 1615685] [NEW] systemd-analyze stats for kernel startup time looks suspect
Public bug reported: I've instrumented a kernel so I can clearly see when processes start and exit, this allows me to see when exactly the kernel has handed off control to userspace. The time the kernel actually takes to initialize compared to the time systemd-analyze reports are different. $ systemd-analyze Startup finished in 16.878s (kernel) + 43.152s (userspace) = 1min 30ms For example: [2.286330] Freeing unused kernel memory: 1532K (b1755000 - b18d4000) [2.296300] Write protecting the kernel read-only data: 12288k [2.304356] Freeing unused kernel memory: 1872K (9d9c6e42c000 - 9d9c6e60) [2.317659] Freeing unused kernel memory: 1208K (9d9c6e8d2000 - 9d9c6ea0) [2.344896] x86/mm: Checked W+X mappings: passed, no W+X pages found. [2.368095] exec: 1 (swapper/0) -> /init [2.377284] _do_fork: 1 init [2.381933] exit 53 init [2.386444] _do_fork: 1 init [2.390741] exit 54 init [2.394899] _do_fork: 1 init and we have the initramfs initialization occurring, and then finally systemd starts: [ 16.571630] exec: 1 (run-init) -> /sbin/init [ 17.287342] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN) [ 17.307892] systemd[1]: Detected virtualization microsoft. [ 17.314765] systemd[1]: Detected architecture x86-64. [ 17.421589] systemd[1]: Set hostname to . So it seems that systemd is accounting initramfs time in the kernel time stats. It would be preferable to be able to report the kernel init time, the initramfs time and the userspace time rather just kernel + userspace. As it stands, the kernel passed off control to systemd at 16.571630 seconds, so I have no no idea why systemd is reporting 16.878 seconds. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- 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/1615685 Title: systemd-analyze stats for kernel startup time looks suspect Status in systemd package in Ubuntu: New Bug description: I've instrumented a kernel so I can clearly see when processes start and exit, this allows me to see when exactly the kernel has handed off control to userspace. The time the kernel actually takes to initialize compared to the time systemd-analyze reports are different. $ systemd-analyze Startup finished in 16.878s (kernel) + 43.152s (userspace) = 1min 30ms For example: [2.286330] Freeing unused kernel memory: 1532K (b1755000 - b18d4000) [2.296300] Write protecting the kernel read-only data: 12288k [2.304356] Freeing unused kernel memory: 1872K (9d9c6e42c000 - 9d9c6e60) [2.317659] Freeing unused kernel memory: 1208K (9d9c6e8d2000 - 9d9c6ea0) [2.344896] x86/mm: Checked W+X mappings: passed, no W+X pages found. [2.368095] exec: 1 (swapper/0) -> /init [2.377284] _do_fork: 1 init [2.381933] exit 53 init [2.386444] _do_fork: 1 init [2.390741] exit 54 init [2.394899] _do_fork: 1 init and we have the initramfs initialization occurring, and then finally systemd starts: [ 16.571630] exec: 1 (run-init) -> /sbin/init [ 17.287342] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN) [ 17.307892] systemd[1]: Detected virtualization microsoft. [ 17.314765] systemd[1]: Detected architecture x86-64. [ 17.421589] systemd[1]: Set hostname to . So it seems that systemd is accounting initramfs time in the kernel time stats. It would be preferable to be able to report the kernel init time, the initramfs time and the userspace time rather just kernel + userspace. As it stands, the kernel passed off control to systemd at 16.571630 seconds, so I have no no idea why systemd is reporting 16.878 seconds. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1615685/+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 1584124] Re: revisit /etc/init.d/ondemand
** Changed in: linux (Ubuntu) Assignee: (unassigned) => Colin Ian King (colin-king) -- 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/1584124 Title: revisit /etc/init.d/ondemand Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Bug description: We've been carrying /etc/init.d/ondemand for many years. We should revisit if booting with a kernel that defaults to "ondemand" right away is still actually slower than "performance". In the short term, systemd should grow a "Type=idle" unit that switches to ondemand, to replace the static "1 minute" sleep. This will also get rid of the last init.d script in "initscripts" that we actually use, and pave the way for dropping the initscripts package. In the long term, we could drop it completely if "ondemand" DTRT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584124/+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 1584124] Re: revisit /etc/init.d/ondemand
Some data to take into consideration. I've tested 4 difference configs (3 laptops, 1 server) of mixed Intel and AMD hardware, comparing the default powersave/ondemand [1] vs performance [1] depends on CPU and if intel-pstate is supported For faster modern Intel CPUs where intel-pstate is supported, there is minimal difference. Otherwise, performance is a ~3% faster, and all the gains are in userspace. See attached spreadsheet. Tests data was gathered from the average of 25 and average of 50 boots per CPU scheduler setting. So that's a total of 600 boots in this dataset across a range of H/W, so I think this data is pretty reliable data. ** Attachment added: "boot-times-performance-vs-powersave-intel-pstate.ods" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584124/+attachment/4679093/+files/boot-times-performance-vs-powersave-intel-pstate.ods -- 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/1584124 Title: revisit /etc/init.d/ondemand Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Bug description: We've been carrying /etc/init.d/ondemand for many years. We should revisit if booting with a kernel that defaults to "ondemand" right away is still actually slower than "performance". In the short term, systemd should grow a "Type=idle" unit that switches to ondemand, to replace the static "1 minute" sleep. This will also get rid of the last init.d script in "initscripts" that we actually use, and pave the way for dropping the initscripts package. In the long term, we could drop it completely if "ondemand" DTRT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584124/+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 1364404] Re: qmlscene is leaking ~1.7K per second on an idle application on the phone
I re-flashed my mako today and tested it again and can reproduce the issue every time I test it. Perhaps you didn't have the display forced on (as described below). How to reproduce: 1. Force the phone not to suspend: powerd-cli display on bright & 2. Start calendar app and find the pid: ps -ef | grep calendar.qml 3. Trace: smemstat -l -p 5236 60 5 Change in memory (average per second): PID Swap USS PSS RSS User Command 5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B PID Swap USS PSS RSS User Command 5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B PID Swap USS PSS RSS User Command 5236 0.0 B 1160.5 B 1160.5 B 1160.5 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml Total: 0.0 B 1160.5 B 1160.5 B 1160.5 B PID Swap USS PSS RSS User Command 5236 0.0 B 1297.1 B 1297.1 B 1297.1 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml Total: 0.0 B 1297.1 B 1297.1 B 1297.1 B PID Swap USS PSS RSS User Command 5236 0.0 B 1228.8 B 1228.8 B 1228.8 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml Total: 0.0 B 1228.8 B 1228.8 B 1228.8 B And one can see that one of the threads is expanding the heap by 4K every ~3 seconds, which correlates with the heap expanding by a over 1K a second: strace -f -t -p 5236 -e memory [pid 5255] 13:11:37 mprotect(0xab0f6000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:40 mprotect(0xab0f7000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:44 mprotect(0xab0f8000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:47 mprotect(0xab0f9000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:50 mprotect(0xab0fa000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:54 mprotect(0xab0fb000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:11:57 mprotect(0xab0fc000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:12:00 mprotect(0xab0fd000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:12:04 mprotect(0xab0fe000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:12:07 mprotect(0xab0ff000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 5255] 13:12:10 mmap2(0xab10, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xab10 [pid 5255] 13:12:10 mprotect(0xab10, 135168, PROT_READ|PROT_WRITE) = 0 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtdeclarative-opensource- src in Ubuntu. https://bugs.launchpad.net/bugs/1364404 Title: qmlscene is leaking ~1.7K per second on an idle application on the phone Status in “qtdeclarative-opensource-src” package in Ubuntu: New Bug description: Running apps on the phone using qmlscene and just keeping *idle* one can see ~1.7K per second of heap growth. I monitored qmlscene for ~570 minutes and observed 58156K of anonymous mapped memory (normally this is heap) growth. Running smemstat on qmlscene, for example, an idle calendar app: ps -ax | grep calendar.qml | grep -v grep 14006 ?Ssl8:26 /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene calendar.qml smemstat -p 14006 60 Change in memory (average per second): PID Swap USS PSS RSS User Command 14006 0.0 B 1706.7 B 1706.7 B 1706.7 B phablet /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene Total: 0.0 B 1706.7 B 1706.7 B 1706.7 B ...etc This seems to be a similar leak rate to bug 1364380 so it may be a common library that is the root of the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1364404/+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 1364404] Re: qmlscene is leaking ~1.7K per second on an idle application on the phone
I think the issue is that a thread is reading sensor data and leaking
memory, I put a breakpoint on mprotect calls and found most are from:
(gdb) where
#0 mprotect () at ../sysdeps/unix/syscall-template.S:82
#1 0xb5eeb19c in grow_heap (diff=4096, h=0xb140) at arena.c:617
#2 sysmalloc (av=0xb1400010, nb=72) at malloc.c:2387
#3 _int_malloc (av=av@entry=0xb1400010, bytes=bytes@entry=64) at malloc.c:3800
#4 0xb5eec122 in __GI___libc_malloc (bytes=64) at malloc.c:2891
#5 0xb60420f4 in operator new(unsigned int) ()
from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#6 0xb629e1a8 in QObject::QObject(QObject*) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#7 0xb3a86eb4 in QSensorReading::QSensorReading(QObject*,
QSensorReadingPrivate*) () from /usr/lib/arm-linux-gnueabihf/libQt5Sensors.so.5
#8 0xb3a890f8 in QAccelerometerReading::QAccelerometerReading(QObject*) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Sensors.so.5
#9 0xb1fb123c in ?? ()
from
/usr/lib/arm-linux-gnueabihf/qt5/plugins/sensors/libqtubuntu_sensors_plugins.so
#10 0xb1f9f9fc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I wonder if the sensor object pool is not freeing memory, there is an
interesting comment:
void core::SharedAccelerometer::onAccelerometerReading(UASAccelerometerEvent
*event)
{
Q_ASSERT(event != NULL);
// TODO(tvoss): We should rely on an object pool to recycle accelerometer
reading
// instances here. We could use a custom deleter for the shared pointer to
put
// instances that have been successfully delivered to slots back into the
pool.
QSharedPointer reading(new QAccelerometerReading());
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtdeclarative-opensource-
src in Ubuntu.
https://bugs.launchpad.net/bugs/1364404
Title:
qmlscene is leaking ~1.7K per second on an idle application on the
phone
Status in “qtdeclarative-opensource-src” package in Ubuntu:
New
Bug description:
Running apps on the phone using qmlscene and just keeping *idle* one
can see ~1.7K per second of heap growth. I monitored qmlscene for
~570 minutes and observed 58156K of anonymous mapped memory (normally
this is heap) growth.
Running smemstat on qmlscene, for example, an idle calendar app:
ps -ax | grep calendar.qml | grep -v grep
14006 ?Ssl8:26 /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene
calendar.qml
smemstat -p 14006 60
Change in memory (average per second):
PID Swap USS PSS RSS User Command
14006 0.0 B 1706.7 B 1706.7 B 1706.7 B phablet
/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene
Total: 0.0 B 1706.7 B 1706.7 B 1706.7 B
...etc
This seems to be a similar leak rate to bug 1364380 so it may be a
common library that is the root of the problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1364404/+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 1364380] Re: unity8-dash is leaking memory at ~1.7K a second
I think it may be related to https://bugs.launchpad.net/ubuntu/+source /qtdeclarative-opensource-src/+bug/1364404/comments/3 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1364380 Title: unity8-dash is leaking memory at ~1.7K a second Status in “unity8” package in Ubuntu: Triaged Bug description: Running smemstat, we can see that unity8-dash is consuming heap at around 1.7K *per second* smemstat -p $(pidof unity8-dash) 10 (leave it to run for a while and you will see the heap growth stats) running strace on the process shows anonymous mmap() increasing the heap every ~10 minutes or so. Over a 570 minute period I observed the process growing by 58MB, which works out to be ~140MB per day. This is a serious heap expansion memory leak. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1364380/+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 1364353] Re: unity8 leaking memory on idle phone
Related bug: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative- opensource-src/+bug/1364404/comments/3 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1364353 Title: unity8 leaking memory on idle phone Status in Qt integration with the Mir display server: New Status in “media-hub” package in Ubuntu: New Status in “qtmir” package in Ubuntu: New Status in “unity8” package in Ubuntu: New Bug description: I've found that on an idle phone, unity8 is very slowly consuming more heap at around 1K every 15-20 minutes. I ran my analysis over 12 hours and found that there are brk()s occurring roughly every 10 minutes and the heap is just increasing in size and never shrinking, indicating a small memory leak. gdb shows: (gdb) where #0 __brk (addr=0x31fa000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28 #1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53 #2 0xb626209a in __GI___default_morecore (increment=) at morecore.c:47 #3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 , nb=72) at malloc.c:2462 #4 _int_malloc (av=av@entry=0xb62f54e8 , bytes=bytes@entry=64) at malloc.c:3800 #5 0xb6260576 in __GI___libc_malloc (bytes=64) at malloc.c:2891 #6 0xb636d0f4 in operator new(unsigned int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #7 0xa92c2b42 in core::dbus::Message::Reader::Reader(std::shared_ptr const&) () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4 #8 0xa92c2cc0 in core::dbus::Message::Reader::pop_variant() () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4 #9 0xa9356a98 in core::dbus::Codec::decode_argument(core::dbus::Message::Reader&, core::dbus::types::Variant&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #10 0xa9374608 in core::dbus::Result >::from_message(std::shared_ptr const&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #11 0xa937484c in core::dbus::Result > core::dbus::Object::invoke_method_synchronously to continue, or q to quit--- s::Properties::Get, core::dbus::types::TypedVariant, std::string, std::string>(std::string const&, std::string const&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #12 0xa9374a98 in core::dbus::Property::get() const () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #13 0xa93c6f66 in AalMediaPlayerService::position() const () from /usr/lib/arm-linux-gnueabihf/qt5/plugins/mediaservice/libaalmediaplayer.so #14 0xaaae6332 in QMediaPlayer::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5 #15 0xb65ac518 in QMetaProperty::read(QObject const*) const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #16 0xaaaba3e2 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) and also: (gdb) where #0 __brk (addr=0x31d9000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28 #1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53 #2 0xb626209a in __GI___default_morecore (increment=) at morecore.c:47 #3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 , nb=128) at malloc.c:2462 #4 _int_malloc (av=av@entry=0xb62f54e8 , bytes=bytes@entry=120) at malloc.c:3800 #5 0xb6260576 in __GI___libc_malloc (bytes=120) at malloc.c:2891 #6 0xb636d0f4 in operator new(unsigned int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #7 0xb3f13224 in mir::scene::BasicSurface::compositor_snapshot(void const*) const () from /usr/lib/arm-linux-gnueabihf/libmirserver.so.24 #8 0xad14caba in qtmir::MirSurfaceItem::dropPendingBuffers() () from /usr/lib/arm-linux-gnueabihf/qt5/qml/Unity/Application/libunityapplicationplugin.so #9 0xb65c4274 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #10 0xb65cca36 in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #11 0xb65c4eca in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #12 0xb65a4f92 in QCoreApplication::notify(QObject*, QEvent*) () ---Type to continue, or q to quit--- from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #13 0xb65a4d88 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #14 0xb65de45a in QTimerInfoList::activateTimers() () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #15 0xb65de70c in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #16 0xb5dbbf50 in g_main_context_dispatch () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0 #17 0xb5dbc0fc in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qtm
[Touch-packages] [Bug 1364353] Re: unity8 leaking memory on idle phone
So the issue is in libubuntu_application_api; so is it related to bug #1206146 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1364353 Title: unity8 leaking memory on idle phone Status in Qt integration with the Mir display server: New Status in “qtmir” package in Ubuntu: New Status in “unity8” package in Ubuntu: Confirmed Bug description: I've found that on an idle phone, unity8 is very slowly consuming more heap at around 1K every 15-20 minutes. I ran my analysis over 12 hours and found that there are brk()s occurring roughly every 10 minutes and the heap is just increasing in size and never shrinking, indicating a small memory leak. gdb shows: (gdb) where #0 __brk (addr=0x31fa000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28 #1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53 #2 0xb626209a in __GI___default_morecore (increment=) at morecore.c:47 #3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 , nb=72) at malloc.c:2462 #4 _int_malloc (av=av@entry=0xb62f54e8 , bytes=bytes@entry=64) at malloc.c:3800 #5 0xb6260576 in __GI___libc_malloc (bytes=64) at malloc.c:2891 #6 0xb636d0f4 in operator new(unsigned int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #7 0xa92c2b42 in core::dbus::Message::Reader::Reader(std::shared_ptr const&) () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4 #8 0xa92c2cc0 in core::dbus::Message::Reader::pop_variant() () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4 #9 0xa9356a98 in core::dbus::Codec::decode_argument(core::dbus::Message::Reader&, core::dbus::types::Variant&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #10 0xa9374608 in core::dbus::Result >::from_message(std::shared_ptr const&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #11 0xa937484c in core::dbus::Result > core::dbus::Object::invoke_method_synchronously to continue, or q to quit--- s::Properties::Get, core::dbus::types::TypedVariant, std::string, std::string>(std::string const&, std::string const&) () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #12 0xa9374a98 in core::dbus::Property::get() const () from /usr/lib/arm-linux-gnueabihf/libmedia-hub-client.so.1 #13 0xa93c6f66 in AalMediaPlayerService::position() const () from /usr/lib/arm-linux-gnueabihf/qt5/plugins/mediaservice/libaalmediaplayer.so #14 0xaaae6332 in QMediaPlayer::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5 #15 0xb65ac518 in QMetaProperty::read(QObject const*) const () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #16 0xaaaba3e2 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Multimedia.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) and also: (gdb) where #0 __brk (addr=0x31d9000) at ../ports/sysdeps/unix/sysv/linux/arm/brk.c:28 #1 0xb6298826 in __GI___sbrk (increment=135168) at sbrk.c:53 #2 0xb626209a in __GI___default_morecore (increment=) at morecore.c:47 #3 0xb625f1e2 in sysmalloc (av=0xb62f54e8 , nb=128) at malloc.c:2462 #4 _int_malloc (av=av@entry=0xb62f54e8 , bytes=bytes@entry=120) at malloc.c:3800 #5 0xb6260576 in __GI___libc_malloc (bytes=120) at malloc.c:2891 #6 0xb636d0f4 in operator new(unsigned int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #7 0xb3f13224 in mir::scene::BasicSurface::compositor_snapshot(void const*) const () from /usr/lib/arm-linux-gnueabihf/libmirserver.so.24 #8 0xad14caba in qtmir::MirSurfaceItem::dropPendingBuffers() () from /usr/lib/arm-linux-gnueabihf/qt5/qml/Unity/Application/libunityapplicationplugin.so #9 0xb65c4274 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #10 0xb65cca36 in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #11 0xb65c4eca in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #12 0xb65a4f92 in QCoreApplication::notify(QObject*, QEvent*) () ---Type to continue, or q to quit--- from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #13 0xb65a4d88 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #14 0xb65de45a in QTimerInfoList::activateTimers() () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #15 0xb65de70c in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #16 0xb5dbbf50 in g_main_context_dispatch () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0 #17 0xb5dbc0fc in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qtmir/+bug/1364353/+subscriptions -- Mailing list: https://launchpad.ne
[Touch-packages] [Bug 1364464] Re: unity8-dash has a thread that is polling rather rapidly on epoll wait
In 60 seconds, one can observe:
% time seconds usecs/call callserrors syscall
-- --- --- - -
44.512.252139 1052 poll
28.031.416574 366 3871 epoll_wait
24.331.23 10250 120 rt_sigtimedwait
2.770.14 7 2 restart_syscall
0.260.013026 2 6306 fcntl64
0.040.002036 1 3153 3153 connect
0.010.000655 0 3213 close
0.010.000607 0 3213 socket
0.010.000529 0 7134 clock_gettime
0.010.000520 1 1026 write
0.010.000352 0 103816 read
0.000.000246 0 985 recvfrom
0.000.98 1 120 madvise
0.000.00 054 ioctl
0.000.00 0 6 gettimeofday
0.000.00 0 120 clone
0.000.00 025 mprotect
0.000.00 0 1 writev
0.000.00 0 1 sched_yield
0.000.00 0 120 rt_sigprocmask
0.000.00 015 5 futex
0.000.00 0 6 bind
0.000.00 0 6 getsockname
0.000.00 012 sendto
0.000.00 07713 recvmsg
0.000.00 0 120 set_robust_list
-- --- --- - -
100.005.054643 31796 3187 total
The 3153 failed connects are to named sockets that don't exist. That's a
rate of 52 PER SECOND. This is rather ridiculous, we are meant to be
trying to make a low power phone last and not drain the battery on this
kind of rapid polling.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1364464
Title:
unity8-dash has a thread that is polling rather rapidly on epoll wait
Status in “unity-scopes-api” package in Ubuntu:
New
Status in “unity-scopes-shell” package in Ubuntu:
New
Status in “unity8” package in Ubuntu:
Incomplete
Bug description:
one of the threads to unity8-dash is creating quite a few wakeups per
second:
# eventstat 60 1
Event/s PID TaskInit Function Callback
13.02 2812 scopes_ng::Scop hrtimer_start_range_nshrtimer_wakeup
process 2812 is a thread of unity8-dash
attaching strace to the thread we see:
root@ubuntu-phablet:/proc# strace -p 2812
Process 2812 attached
clock_gettime(CLOCK_MONOTONIC, {925, 47970238}) = 0
epoll_wait(57, {}, 256, 115)= 0
clock_gettime(CLOCK_MONOTONIC, {925, 165670469}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 174626930}) = 0
epoll_wait(57, {}, 256, 39) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 215561930}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 222932007}) = 0
epoll_wait(57, {}, 256, 65) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 290266777}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
..ad infinitum...
the epoll_wait() is sleeping a very short while before a connect to a
clickscope named socket path is attempted over and over again. Is this
rapid polling really necessary? It's contributing to 0.50%-1.00% of
the CPU load of the phone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1364464/+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 1364464] Re: unity8-dash has a thread that is polling rather rapidly on epoll wait
Test scenario:
Clean install with developer mode so I can access the device via adb
shell. Device is on the lock screen, sitting idle, so essentially is
should be doing not a lot.
I ran eventstat to see which processes are generating the most wakeups:
root@ubuntu-phablet:~# eventstat 60 1
Event/s PID TaskInit Function Callback
87.00 0 [swapper/0] hrtimer_start_range_nstick_sched_timer
39.05 3759 scopes_ng::Scop hrtimer_start_range_nshrtimer_wakeup
16.68 5 [kworker/u:0] hwmsen_work_func hwmsen_poll
10.00 3951 ubuntu-location hrtimer_start_range_nshrtimer_wakeup
Then I strace'd PID 3759,
strace -p 3759 -e connect
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1364464
Title:
unity8-dash has a thread that is polling rather rapidly on epoll wait
Status in “unity-scopes-api” package in Ubuntu:
New
Status in “unity-scopes-shell” package in Ubuntu:
New
Status in “unity8” package in Ubuntu:
Incomplete
Bug description:
one of the threads to unity8-dash is creating quite a few wakeups per
second:
# eventstat 60 1
Event/s PID TaskInit Function Callback
13.02 2812 scopes_ng::Scop hrtimer_start_range_nshrtimer_wakeup
process 2812 is a thread of unity8-dash
attaching strace to the thread we see:
root@ubuntu-phablet:/proc# strace -p 2812
Process 2812 attached
clock_gettime(CLOCK_MONOTONIC, {925, 47970238}) = 0
epoll_wait(57, {}, 256, 115)= 0
clock_gettime(CLOCK_MONOTONIC, {925, 165670469}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 174626930}) = 0
epoll_wait(57, {}, 256, 39) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 215561930}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 222932007}) = 0
epoll_wait(57, {}, 256, 65) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 290266777}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
..ad infinitum...
the epoll_wait() is sleeping a very short while before a connect to a
clickscope named socket path is attempted over and over again. Is this
rapid polling really necessary? It's contributing to 0.50%-1.00% of
the CPU load of the phone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1364464/+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 1372413] Re: Extensive battery drain on RTM
Also, it would be useful to capture activity of the system using the following over a 10 minute period Still using ppa:colin-king/white: sudo apt-get install eventstat cpustat fnotifystat forkstat sudo eventstat 10 60 > eventstat.log (10 seconds of sampling, 60 x a second) And see if the CPU is busy: sudo cpustat 10 60 > cpustat.log And see if the file system is busy: sudo fnotifystat 10 60 > fnotifystat.log And see if there is excessive thread or process creation: sudo forkstat -D 600 > forkstat.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I compared a 10 minute sleep from an image from pre-Christmas to the latest RTM image and I see better deep suspend stats with the latest image (see attached). If Thomas can attach all the syslog files from /var/log/syslog we can parse this with suspend-blocker and get an idea of what's been going on. The stats you attached Pat look reasonable for the mako, it does pop out of deep suspend every 60 or so seconds for a short while to handle events from the modem front end. ** Attachment added: "tar file of old vs new suspend-blocker output" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299177/+files/suspend-blocker.tar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I compared a 10 minute sleep from an image from pre-Christmas to the latest RTM image and I see better deep suspend stats with the latest image (see attached). If Thomas can attach all the syslog files from /var/log/syslog we can parse this with suspend-blocker and get an idea of what's been going on. The stats you attached Pat look reasonable for the mako, it does pop out of deep suspend every 60 or so seconds for a short while to handle events from the modem front end. ** Attachment added: "tar file of old vs new suspend-blocker output" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299178/+files/suspend-blocker.tar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I compared 10 minutes of file access activity (old pre-Christmas image vs lastest RTM image) and I'm seeing a lot more udevd activity on /lib/udev/rules.d, /etc/modprobe.d and /etc/group. See attached files (spreadsheet and old vs new file activity logs). ** Attachment added: "tar of old vs new file activity logs and spreadsheet" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299202/+files/file-access.tar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I also compared 10 minutes of file process wakeup activity (old pre- Christmas image vs lastest RTM image) and I'm seeing little different between old vs new, so no obvious regressions there. See attached files (spreadsheet and old vs new file activity logs). ** Attachment added: "wakeup-events.tar" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299220/+files/wakeup-events.tar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I've written a bash script to periodically grab battery capacity levels over some of this afternoon and projected the expected duration (making an assumption the battery drain is linear, which it is not, i know that). Anyhow, I predict > 30+ hours of idle on a default clean install on deep sleep. See attached spreadsheet. I will update the bug with the complete data tomorrow. ** Attachment added: "mako-battery-drain.ods" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299366/+files/mako-battery-drain.ods -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: Confirmed Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
With wifi associated to a fairly "busy" AP that produces regular beacon intervals with CTS protection mode enabled and also phone data enabled I'm seeing ~24+ hours on deep sleep idle. With wifi enabled, I'm seeing ~7.5 wifi related wakeups per minute. I then disabled wifi and these wakeups disappear. So the bottom line is that wifi in deep sleep is the root cause of extraneous wakeups. Now depending on how busy the AP is and the kinds of packets, it may cause more or less wakeups, hence different drain characteristics. I'll recharge the phone and see how the wifi disabled case changes the battery drain rate. Attached is two-page spreadsheet of my drain results and also stats on wakeups from deep sleep caused by wifi related wakeup events. ** Attachment added: "wifi related battery drain stats" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4299973/+files/mako-rtm-battery-drain-12hrs.ods -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
Any chance of getting that syslog to see what's going on? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
FYI, For my tests, I am reading the battery capacity directly, just to keep it as light weight as possible: #!/bin/sh rm -f battery.log while true do c=$(cat /sys/devices/platform/battery/power_supply/battery/capacity) d=$(date "+%d/%m/%Y %H:%M:%S") echo "$d $c" >> battery.log sleep 2 done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
Pat, do you mind attaching the entire cpustat.log so I spot any specific trends? Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
We could possibly attach health-check to powerd to see what activity is going. E.g. health-check -r -w -W -f -c -p upowerd -d 3600 > health-check.log ..that will attach health-check for 1 hour and dump the results into health-check.log. Colin -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
Pat, I use something such like the following awk script to parse the
data:
{
if ((NF == 5) && ($4 != "PID")) {
total[$4] += $1
usr[$4] += $2
sys[$4] += $3
cmd[$4] = $5
}
if ((NF == 5) && ($4 == "PID"))
n++
}
END {
for (i in total)
printf "%10.2f %10.2f %10.2f %s\n", total[i], usr[i], sys[i],
cmd[i]
}
awk -f cpustat.awk < cpustat.log | sort -nr | head -20
20400.32 19276.851123.57 /usr/lib/upower/upowerd
3503.492570.89 932.58 unity8
3243.72 870.172373.55 cpustat
2911.391710.021201.39 /lib/systemd/systemd-udevd
2207.87 182.062025.80 /system/bin/mpdecision
2133.322012.62 120.71 dbus-daemon
2125.581751.23 374.36 messaging-app
1280.77 0.001280.77 [mmcqd/0]
675.34 0.00 675.34 [jbd2/mmcblk0p23]
449.83 159.82 289.96 unity-system-compositor
412.58 312.51 100.07 NetworkManager
372.17 206.53 165.64 init
355.62 259.23 96.40 /sbin/init
323.53 0.00 323.53 [MC_Thread]
315.88 278.62 37.27 /usr/bin/powerd
310.32 268.82 41.50
/usr/lib/arm-linux-gnueabihf/indicator-power/indicator-power-service
267.14 237.61 29.54 maliit-server
228.89 12.30 216.59 /sbin/healthd
200.54 169.84 30.70
/custom/vendor/here/location-provider/bin/arm-linux-gnueabihf/posclientd
182.56 14.76 167.79 /init
So it does seem that upowerd is consuming the most cycles. Attached is
a spreadsheet and a graph from the raw stats
** Attachment added: "upowerd-cpu-utilisation.ods"
https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4315479/+files/upowerd-cpu-utilisation.ods
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to powerd in Ubuntu.
https://bugs.launchpad.net/bugs/1372413
Title:
Extensive battery drain on RTM
Status in the base for Ubuntu mobile products:
In Progress
Status in powerd package in Ubuntu:
Confirmed
Bug description:
Mako, RTM 1
Since upgrading to RTM the battery life is really poor. What used to
be a battery drain of 5-10% per hour (which is still high) is now
10-15% per hour. Sometimes the phone runs really hot, so there seem to
be something going on in the background that is consuming power. I
mostly have bluetooth, GPS (which isn't always working), wifi and
cellular on, but that's no difference from when I was running 'devel-
proposed' with MultiROM with much less battery consumption.
As an example, I started with a full charge at 7am. After some web
surfing (<15 mins) and watching a couple of youtube videos (on wifi)
battery was down to 66% at 9:15. That's 34% in just over two hours! I
recharged again before lunch and had the phone idle until coming back
1 hour and 45 mins later to find only 75% of battery left, this time
without the phone running particularly hot.
To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
So there is a rise of activity with systemd-udev at the same time that upowerd gets busy too -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I've correlated each processes against the spike in activity for upowerd and also see that mpdecision and systemd-udevd also change their behaviors at that transition. See attached spreadsheet. ** Attachment added: "upowerd-procs.ods" https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1372413/+attachment/4315533/+files/upowerd-procs.ods -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1372413] Re: Extensive battery drain on RTM
I noticed that at this point, the syslog shows and incoming call occurred. After that, the phone does NOT deep suspend at all. Eventually, the phone drains at 03:55:33 on the 7th of Feb. So I think somebody needs to look at the way incoming calls seem to block deep suspend. Feb 6 17:12:05 ubuntu-phablet kernel: [ 1535.537188] suspend: abort suspend Feb 6 17:12:06 ubuntu-phablet powerd[948]: message repeated 3 times: [ signalling activity via HAL] Feb 6 17:12:06 ubuntu-phablet powerd[948]: incoming call Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.243247] request_suspend_state: wakeup (3->0) at 1537348691404 (2015-02-06 22:12:06.717124433 UTC) Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.243399] [Touch D]touch enable Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.249046] mipi_dsi_panel_power: mipi lcd function started status = 1 Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.252739] mipi_dsi_panel_power : reset start. Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.278162] mipi_lgit_lcd_on started Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.335418] mipi_lgit_lcd_on finished Feb 6 17:12:06 ubuntu-phablet kernel: [ 1537.341950] lm3530_backlight_on, ++ lm3530_backlight_on -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to powerd in Ubuntu. https://bugs.launchpad.net/bugs/1372413 Title: Extensive battery drain on RTM Status in the base for Ubuntu mobile products: In Progress Status in powerd package in Ubuntu: Confirmed Bug description: Mako, RTM 1 Since upgrading to RTM the battery life is really poor. What used to be a battery drain of 5-10% per hour (which is still high) is now 10-15% per hour. Sometimes the phone runs really hot, so there seem to be something going on in the background that is consuming power. I mostly have bluetooth, GPS (which isn't always working), wifi and cellular on, but that's no difference from when I was running 'devel- proposed' with MultiROM with much less battery consumption. As an example, I started with a full charge at 7am. After some web surfing (<15 mins) and watching a couple of youtube videos (on wifi) battery was down to 66% at 9:15. That's 34% in just over two hours! I recharged again before lunch and had the phone idle until coming back 1 hour and 45 mins later to find only 75% of battery left, this time without the phone running particularly hot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1372413/+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 1348784] Re: dbus invoked while in recovery mode
** Summary changed: - thermald prevents unmounting /dev/sda1 in recovery mode + dbus invoked while in recovery mode ** Changed in: thermald (Ubuntu) Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1348784 Title: dbus invoked while in recovery mode Status in “thermald” package in Ubuntu: Invalid Status in “upstart” package in Ubuntu: New Bug description: I'm using Ubuntu 14.10 dev with thermald 1.2-1 and if the system is started in the recovery mode it is not possible to unmount /dev/sda1 because thermald is running. Interestingly lsof hasn't even showed that something has a file descriptor on /dev/sda1 open but executing "stop thermald" has worked as a workaround. --- ApportVersion: 2.14.7-0ubuntu2 Architecture: amd64 DistroRelease: Ubuntu 14.10 EcryptfsInUse: Yes NonfreeKernelModules: fglrx Package: upstart 1.13.2-0ubuntu1 PackageArchitecture: amd64 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.16.0-18-generic root=UUID=af27feae-4c9e-4b5f-a1e1-900c0e71c5cb ro elevator=cfq ProcVersionSignature: Ubuntu 3.16.0-18.25-generic 3.16.3 Tags: utopic Uname: Linux 3.16.0-18-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UpstartBugCategory: System UpstartRunningSystemVersion: init (upstart 1.13.2) UserGroups: _MarkForUpload: True modified.conffile..etc.lxdm.lxdm.conf: [modified] mtime.conffile..etc.init.control.alt.delete.conf: 2012-05-05T17:10:11.434470 mtime.conffile..etc.init.tty2.conf: 2014-05-29T05:14:16.791093 mtime.conffile..etc.init.tty3.conf: 2012-05-05T17:10:49.238469 mtime.conffile..etc.init.tty4.conf: 2012-05-05T17:10:58.066468 mtime.conffile..etc.init.tty5.conf: 2012-05-05T17:11:02.938468 mtime.conffile..etc.init.tty6.conf: 2012-05-05T17:11:09.442468 mtime.conffile..etc.lxdm.lxdm.conf: 2012-12-23T19:04:26.948844 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1348784/+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 1364464] Re: unity8-dash has a thread that is polling rather rapidly on epoll wait
Great! Thanks!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1364464
Title:
unity8-dash has a thread that is polling rather rapidly on epoll wait
Status in “unity-scopes-api” package in Ubuntu:
In Progress
Status in “unity-scopes-shell” package in Ubuntu:
Invalid
Status in “unity8” package in Ubuntu:
Invalid
Bug description:
one of the threads to unity8-dash is creating quite a few wakeups per
second:
# eventstat 60 1
Event/s PID TaskInit Function Callback
13.02 2812 scopes_ng::Scop hrtimer_start_range_nshrtimer_wakeup
process 2812 is a thread of unity8-dash
attaching strace to the thread we see:
root@ubuntu-phablet:/proc# strace -p 2812
Process 2812 attached
clock_gettime(CLOCK_MONOTONIC, {925, 47970238}) = 0
epoll_wait(57, {}, 256, 115)= 0
clock_gettime(CLOCK_MONOTONIC, {925, 165670469}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 174626930}) = 0
epoll_wait(57, {}, 256, 39) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 215561930}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(50, {sa_family=AF_LOCAL,
sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file
or directory)
close(50) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 222932007}) = 0
epoll_wait(57, {}, 256, 65) = 0
clock_gettime(CLOCK_MONOTONIC, {925, 290266777}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
fcntl64(50, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
..ad infinitum...
the epoll_wait() is sleeping a very short while before a connect to a
clickscope named socket path is attempted over and over again. Is this
rapid polling really necessary? It's contributing to 0.50%-1.00% of
the CPU load of the phone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1364464/+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 1348784] Re: thermald prevents unmounting /dev/sda1 in recovery mode
Indeed, this does seem to be an upstart/init config issue rather than a thermald issue per se. I'll add that to the "affects" part of the bug report. ** Also affects: upstart (Ubuntu) Importance: Undecided Status: New ** Changed in: upstart (Ubuntu) Assignee: (unassigned) => James Hunt (jamesodhunt) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1348784 Title: thermald prevents unmounting /dev/sda1 in recovery mode Status in “thermald” package in Ubuntu: In Progress Status in “upstart” package in Ubuntu: New Bug description: I'm using Ubuntu 14.10 dev with thermald 1.2-1 and if the system is started in the recovery mode it is not possible to unmount /dev/sda1 because thermald is running. Interestingly lsof hasn't even showed that something has a file descriptor on /dev/sda1 open but executing "stop thermald" has worked as a workaround. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1348784/+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 1348784] Re: thermald prevents unmounting /dev/sda1 in recovery mode
BTW, I'm going to slip the run level changes into thermald to address another thermald bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1348784 Title: thermald prevents unmounting /dev/sda1 in recovery mode Status in “thermald” package in Ubuntu: In Progress Status in “upstart” package in Ubuntu: New Bug description: I'm using Ubuntu 14.10 dev with thermald 1.2-1 and if the system is started in the recovery mode it is not possible to unmount /dev/sda1 because thermald is running. Interestingly lsof hasn't even showed that something has a file descriptor on /dev/sda1 open but executing "stop thermald" has worked as a workaround. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1348784/+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
