from:"Ian"

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

2023-07-11 Thread Colin Ian King

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 2031352] Re: Ubuntu 22.04.3 LTS stuck on power-off/reboot screen

2023-08-28 Thread Ian Russel Adem

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

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

Title:
  Ubuntu 22.04.3 LTS stuck on power-off/reboot screen

Status in linux-hwe-6.2 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in linux-hwe-6.2 source package in Jammy:
  Confirmed

Bug description:
  After updating to Kernel 6.2 a few days ago, I have been experiencing
  issues with my system's shutdown and reboot functions. During these
  processes, the system becomes unresponsive and hangs on a black
  screen, which displays both the Dell and Ubuntu logos. This issue is
  inconsistent; it happens sporadically. Currently, the only workaround
  I've found to successfully shut down the system is to forcibly power
  off the machine by holding down the power button for 5 seconds.

  I've also tested a fresh installation of Ubuntu 22.04.3.

  

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd 249.11-0ubuntu3.9
  ProcVersionSignature: Ubuntu 6.2.0-26.26~22.04.1-generic 6.2.13
  Uname: Linux 6.2.0-26-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Aug 14 22:41:14 2023
  InstallationDate: Installed on 2023-08-14 (1 days ago)
  InstallationMedia: Ubuntu 22.04.3 2023.08.13 LTS (20230813)
  MachineType: Dell Inc. XPS 8930
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-26-generic 
root=UUID=14d1ee7a-565f-4ba4-b6dd-7bc16e487451 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/14/2023
  dmi.bios.release: 1.1
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.1.30
  dmi.board.name: 0T88YD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: Not Specified
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.1.30:bd03/14/2023:br1.1:svnDellInc.:pnXPS8930:pvr1.1.30:rvnDellInc.:rn0T88YD:rvrA00:cvnDellInc.:ct3:cvrNotSpecified:sku0859:
  dmi.product.family: XPS
  dmi.product.name: XPS 8930
  dmi.product.sku: 0859
  dmi.product.version: 1.1.30
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.default.apport:
   # set this to 0 to disable apport, or to 1 to enable it
   # you can temporarily override this with
   # sudo service apport start force_start=1
   enabled=0
  mtime.conffile..etc.default.apport: 2023-08-13T20:57:27
  mtime.conffile..etc.systemd.system.conf: 2023-08-13T20:57:27

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

2023-09-14 Thread Colin Ian King

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 1045072] Re: bash generates spurious DEL on empty variable interpolation

2015-05-24 Thread Ian! D. Allen

This bug is gone in Ubuntu 12.04 using bash 4.2.25(1)-release

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

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

Title:
  bash generates spurious DEL on empty variable interpolation

Status in bash package in Ubuntu:
  Fix Released

Bug description:
  #!/bin/bash -u
  # BASH BUG: spurious DEL characters appear on empty variable interpolation.
  # BASH 4.2.8(1)-release
  # Script works fine (expected output) using /bin/dash.
  # -Ian! D. Allen - idal...@idallen.ca - www.idallen.com

  a=''

  {
  echo correct "$a"   # correct empty output line
  echo correct "$a""$a"   # correct empty output line
  echo correct "$a""$a""$a"   # correct empty output line
  echo XwrongX "$a""$a""$a""$a"   # spurious two DEL chars appear at line end
  echo correct a"$a"  # correct single "a" on line
  echo XwrongX a"$a""$a"  # spurious DEL char appears at line end
  echo correct a"$a$a"# correct single "a" on line
  echo correct a"$a$a$a$a"# correct single "a" on line
  } | cat -v

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: bash 4.2-0ubuntu3
  ProcVersionSignature: Ubuntu 2.6.38-15.66-generic 2.6.38.8
  Uname: Linux 2.6.38-15-generic x86_64
  Architecture: amd64
  Date: Sun Sep  2 15:36:55 2012
  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
  SourcePackage: bash
  UpgradeStatus: No upgrade log present (probably fresh install)

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

2015-03-30 Thread Colin Ian King

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

2015-03-30 Thread Colin Ian King

** 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

2015-03-31 Thread Colin Ian King

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

2015-03-31 Thread Colin Ian King

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

2015-03-31 Thread Colin Ian King

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 1370704] Re: tracker-extract crashed with SIGSEGV in gst_base_parse_push_frame()

2015-04-02 Thread Ian W Scott

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

How am I supposed to follow these instructions if the linked bug is
private and I can't even read it?

"Please look at the other bug report to see if there is any missing
information that you can provide, or to see if there is a workaround for
the bug. Additionally, any further discussion regarding the bug should
occur in the other report."

It's extemely frustrating to be told "just look here" and find that
"here" is something I'm not allowed look at!

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

Title:
  tracker-extract crashed with SIGSEGV in gst_base_parse_push_frame()

Status in tracker package in Ubuntu:
  Confirmed

Bug description:
  On Gnome Startup

  ProblemType: Crash
  DistroRelease: Ubuntu 14.10
  Package: tracker-extract 1.0.4-0ubuntu1
  Uname: Linux 3.16.2-031602-generic x86_64
  NonfreeKernelModules: fglrx wl
  ApportVersion: 2.14.7-0ubuntu2
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: GNOME
  Date: Wed Sep 17 22:47:41 2014
  ExecutablePath: /usr/lib/tracker/tracker-extract
  InstallationDate: Installed on 2014-09-08 (9 days ago)
  InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 
(20140826)
  ProcCmdline: /usr/lib/tracker/tracker-extract
  ProcEnviron:
   LD_LIBRARY_PATH=
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x7f45828630a8:mov%rbx,0x48(%rax)
   PC (0x7f45828630a8) ok
   source "%rbx" ok
   destination "0x48(%rax)" (0x0048) not located in a known VMA region 
(needed writable region)!
   Stack memory exhausted (SP below stack segment)
  SegvReason: writing NULL VMA
  Signal: 11
  SourcePackage: tracker
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0
   ?? () from /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0
   ?? () from /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0
   ?? () from /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
   gst_base_parse_push_frame () from 
/usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
  Title: tracker-extract crashed with SIGSEGV in gst_base_parse_push_frame()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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

2015-03-18 Thread Colin Ian King

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

2015-07-02 Thread Colin Ian King

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

2015-07-06 Thread Colin Ian King

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

2015-07-10 Thread Colin Ian King

** 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

2015-07-13 Thread Colin Ian King

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

2015-07-23 Thread Colin Ian King

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

2014-07-31 Thread Colin Ian King

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

2014-08-01 Thread Colin Ian King

** 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

2017-02-01 Thread Colin Ian King

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

2017-02-01 Thread Colin Ian King

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

2017-02-27 Thread Colin Ian King

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

2017-02-27 Thread Colin Ian King

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 1629649] Re: Ubuntu 16.10 bluetooth doesn't work

2017-05-29 Thread Ian De Silva

** Tags added: zesty

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

Title:
  Ubuntu 16.10 bluetooth doesn't work

Status in bluez package in Ubuntu:
  Confirmed

Bug description:
   0
  down vote
  favorite


  I'm trying unsuccessfully to connect headphone via bluetooth.
  Configuration: Ubuntu-gnome 16:10, Dell XPS-15. lspci shows:

  06:00.0 Network controller: Broadcom Limited BCM4352 802.11ac Wireless
  Network Adapter (rev 03)

  lsusb shows:

  Bus 003 Device 004: ID 0a5c:216f Broadcom Corp. BCM20702A0 Bluetooth

  Below is what I see in my syslog:

  Sep 27 18:19:22 alex-XPS-15-9530 /usr/lib/gdm3/gdm-x-session[4781]: (II) 
modeset(0): Modeline "1920x1080"x60.0  172.80  1920 2040 2248 2576  1080 1081 
1084 1118 -hsync +vsync (67.1 kHz e)
  Sep 27 18:19:22 alex-XPS-15-9530 gnome-control-c[6754]: Ignoring launcher 
gufw (missing desktop file)
  Sep 27 18:19:22 alex-XPS-15-9530 gnome-control-c[6754]: Ignoring launcher 
landscape-client-settings (missing desktop file)
  Sep 27 18:19:22 alex-XPS-15-9530 gnome-control-c[6754]: Ignoring launcher 
ubuntuone-installer (missing desktop file)
  Sep 27 18:19:22 alex-XPS-15-9530 dbus-daemon[4819]: Activating via systemd: 
service name='org.bluez.obex' unit='dbus-org.bluez.obex.service'
  Sep 27 18:19:22 alex-XPS-15-9530 dbus-daemon[4819]: Activation via systemd 
failed for unit 'dbus-org.bluez.obex.service': Unit dbus-org.bluez.obex.service 
not found.
  Sep 27 18:20:29 alex-XPS-15-9530 systemd[1]: Starting Cleanup of Temporary 
Directories...
  Sep 27 18:20:29 alex-XPS-15-9530 systemd-tmpfiles[6783]: 
[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
  Sep 27 18:20:29 alex-XPS-15-9530 systemd[1]: Started Cleanup of Temporary 
Directories.
  Sep 27 18:20:41 alex-XPS-15-9530 bluetoothd[6689]: a2dp-sink profile connect 
failed for 00:18:16:07:03:FD: Protocol not available

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1629649/+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] [NEW] softlockup DoS causes systemd-journald.service to abort with SIGABORT

2017-06-09 Thread Colin Ian King

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 1364780] Re: tracker-extract crashed with SIGABRT in g_malloc0()

2015-08-04 Thread Ian W Scott

In answer to @martyn-lanedo: I'm not sure how to reproduce this
reliably, except that it happens for me in *every* ubuntu-gnome session
(15.04) within 15 minutes or so of login. But it seems to be triggered
by a background tracker action, not by an attempt to extract a
particular file directly. If you can suggest a way of identifying which
file was being extracted at the time of the crash, I can try to identify
it.

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

Title:
  tracker-extract crashed with SIGABRT in g_malloc0()

Status in tracker package in Ubuntu:
  Confirmed

Bug description:
  Logged into ubuntu-gnome guest vm installed in virtualbox. Encountered
  this crash.

  ProblemType: Crash
  DistroRelease: Ubuntu 14.10
  Package: tracker-extract 1.0.4-0ubuntu1
  ProcVersionSignature: Ubuntu 3.16.0-12.18-generic 3.16.1
  Uname: Linux 3.16.0-12-generic x86_64
  ApportVersion: 2.14.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep  2 23:32:05 2014
  ExecutablePath: /usr/lib/tracker/tracker-extract
  InstallationDate: Installed on 2014-08-10 (23 days ago)
  InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 
(20140730)
  ProcCmdline: /usr/lib/tracker/tracker-extract
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  Signal: 6
  SourcePackage: tracker
  StacktraceTop:
   g_malloc0 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_slice_free1 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
   g_queue_pop_tail () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
   ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
   ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  Title: tracker-extract crashed with SIGABRT in g_malloc0()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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

2016-09-22 Thread Colin Ian King

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

2016-09-22 Thread Colin Ian King

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 1536353] Re: [regression] Printer drivers install is broken as lsb package is not available anymore

2016-07-14 Thread Ian M. Stewart

So can anyone confirm if this has fixed the problems with Google Earth
as well?  I don't have an Epson printer any more, but would like to use
Google Earth.

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

Title:
  [regression] Printer drivers install is broken as lsb package is not
  available anymore

Status in cups-filters package in Ubuntu:
  Fix Released
Status in epson-inkjet-printer-escpr package in Ubuntu:
  Fix Released
Status in lsb package in Ubuntu:
  Fix Released
Status in cups-filters source package in Xenial:
  Fix Released
Status in epson-inkjet-printer-escpr source package in Xenial:
  Fix Released
Status in lsb source package in Xenial:
  Fix Released

Bug description:
  [SRU justification]
  Previous releases were compatible with third-party printer drivers provided 
in LSB package format (and also as .deb packages depending on the lsb package). 
 As of 16.04, because the LSB specifies ABIs for various libraries that are no 
longer supported in Ubuntu as obsolete, the packages for the lsb modules have 
been dropped in both Debian and Ubuntu.  This includes dropping of lsb-core, 
which is the component which provides the LSB-mandated ELF loader path - 
without which no lsb executable will work.

  This SRU will restore the bare minimum of LSB compatibility necessary
  to support known third-party LSB printer driver packages on Ubuntu
  16.04.

  [Regression potential]
  The reintroduced 'lsb' binary package is known to not fully satisfy the 
requirements for a complete LSB-compliant system.  This is a regression vs. 
Ubuntu 14.04; so anyone using LSB packages on Ubuntu 14.04 who upgrades to 
Ubuntu 16.04 may have the upgrade succeed without any warning from the package 
manager.

  As there are very few lsb packages in use in the wild, this is
  considered an acceptable regression, especially as this will land
  before the first 16.04 point release.

  [Test case]
  1. Download the epsion 201106w printer driver package from 
http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/main/binary-amd64/epson-inkjet-printer-201106w_1.0.1-1lsb3.2_amd64.deb
  2. Install the package and confirm that its dependencies are not satisfiable.
  3. Enable xenial-proposed.
  4. Install the package again and confirm that the dependencies are satisfied.
  5. Verify that 
/opt/epson-inkjet-printer-201106w/cups/lib/filter/epson_inkjet_printer_filter 
can be run without errors about missing lsb ld.so or missing libraries.

  Starting with Xenial, lsb compatibility packages were dropped (besides
  lsb-release and lsb-base):

  lsb (9.20150826) unstable; urgency=low

    * Drop all the LSB compatibility packages besides lsb-release and lsb-base
  - Drop packages-availability checking in lsb-release
  - Truncate README.Debian to a minimum
  - Document this in lsb-base.NEWS.Debian
    * Change the versioning number to avoid any ambiguity; use joeyh's
  version.date, with version being Debian next stable's

   -- Didier Raboud   Wed, 26 Aug 2015 12:00:00 +0200

  The problem is that downloadable printer drivers (like the ones from
  Openprinting, but also from other available providers) that are
  suggested when installing a printer on Ubuntu depends on lsb, which is
  not available anymore:

  epson-inkjet-printer-201106w:
   Dépend: lsb (>=3.2) but it is not installable

  This triggers a regression where it is not possible to setup a printer
  this way (downloading a driver where no local driver is available)
  anymore.

  I see two possible solutions:

  - Add a proper replaces field to one of the remaining lsb-* packages,
  to hopefully fix missing lsb package (maybe it would be useful to also
  replace other compability packages that are not built anymore).

  - Re-introduce LSB compatibility packages, but that might be an
  overkill.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1536353/+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] [NEW] initramfs waits for 5 seconds when executing /scripts/local-premount/resume

2016-08-22 Thread Colin Ian King

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

2016-08-22 Thread Colin Ian King

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 1577303] [NEW] package systemd-sysv 229-4ubuntu4 failed to install/upgrade: pre-dependency problem - not installing systemd-sysv

2016-05-01 Thread ian jeffery matthews

Public bug reported:

Several errors reported during installation, all seemd related to
amd-64.

However on reboot, everything seems to be working, but the system has
aksed for several erros reports, all of which have been completed.  This
post is therefore responding to system requests and has not been
initiated by me

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: systemd-sysv 229-4ubuntu4
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Mon May  2 07:10:09 2016
ErrorMessage: pre-dependency problem - not installing systemd-sysv
InstallationDate: Installed on 2016-01-29 (93 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1
 apt  1.2.10ubuntu1
SourcePackage: systemd
Title: package systemd-sysv 229-4ubuntu4 failed to install/upgrade: 
pre-dependency problem - not installing systemd-sysv
UpgradeStatus: Upgraded to xenial on 2016-05-02 (0 days ago)

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package xenial

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

Title:
  package systemd-sysv 229-4ubuntu4 failed to install/upgrade: pre-
  dependency problem - not installing systemd-sysv

Status in systemd package in Ubuntu:
  New

Bug description:
  Several errors reported during installation, all seemd related to
  amd-64.

  However on reboot, everything seems to be working, but the system has
  aksed for several erros reports, all of which have been completed.
  This post is therefore responding to system requests and has not been
  initiated by me

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: systemd-sysv 229-4ubuntu4
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Mon May  2 07:10:09 2016
  ErrorMessage: pre-dependency problem - not installing systemd-sysv
  InstallationDate: Installed on 2016-01-29 (93 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1
   apt  1.2.10ubuntu1
  SourcePackage: systemd
  Title: package systemd-sysv 229-4ubuntu4 failed to install/upgrade: 
pre-dependency problem - not installing systemd-sysv
  UpgradeStatus: Upgraded to xenial on 2016-05-02 (0 days ago)

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

2016-05-20 Thread Colin Ian King

** 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

2016-06-07 Thread Colin Ian King

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

2014-09-15 Thread Colin Ian King

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

2014-09-18 Thread Colin Ian King

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

2014-09-22 Thread Colin Ian King

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

2015-01-14 Thread Colin Ian King

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).

** 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

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

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

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

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

2015-01-16 Thread Colin Ian King

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

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

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

2014-10-31 Thread Colin Ian King

** 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

2014-09-25 Thread Colin Ian King

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

2014-09-25 Thread Colin Ian King

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

2014-09-25 Thread Colin Ian King

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

[Touch-packages] [Bug 1348784] Re: thermald prevents unmounting /dev/sda1 in recovery mode

2014-09-29 Thread Colin Ian King

@James, any idea why dbus is starting?

** Changed in: upstart (Ubuntu)
   Importance: Undecided => Medium

-- 
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 1376302] [NEW] indicator-network is frequently logging to /home/phablet/.cache/upstart/indicator-network.log

Public bug reported:

I was trying to figure out where excessive file system writes were
coming from (to try to reduce flash writes and hence reduce power
consumption) and I spotted that /home/phablet/.cache/upstart/indicator-
network.log is being written to rather often (every minute or so) (tail
-f the log and see what I mean).

On my phone it the log seems to be being filled with the same 3 types of
messages over and over:

void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileCountryCode
void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileNetworkCode
void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: CellId

I guess these look like some kind of error message from ofono.  In the
period of an hour I see ~28K of messages being written, which although
isn't huge, it is extra work for the system to write and I think the
messages may need looking into and investigating.

** Affects: indicator-network (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- indicator-network is frequenly logging to 
/home/phablet/.cache/upstart/indicator-network.log
+ indicator-network is frequently logging to 
/home/phablet/.cache/upstart/indicator-network.log

** Description changed:

  I was trying to figure out where excessive file system writes were
  coming from (to try to reduce flash writes and hence reduce power
  consumption) and I spotted that /home/phablet/.cache/upstart/indicator-
  network.log is being written to rather often (every minute or so) (tail
  -f the log and see what I mean).
  
  On my phone it the log seems to be being filled with the same 3 types of
  messages over and over:
  
  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileCountryCode
  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileNetworkCode
  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: CellId
  
  I guess these look like some kind of error message from ofono.  In the
  period of an hour I see ~28K of messages being written, which although
  isn't huge, it is extra work for the system to write and I think the
- messages may need looking.
+ messages may need looking into and investigating.

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

Title:
  indicator-network is frequently logging to
  /home/phablet/.cache/upstart/indicator-network.log

Status in “indicator-network” package in Ubuntu:
  New

Bug description:
  I was trying to figure out where excessive file system writes were
  coming from (to try to reduce flash writes and hence reduce power
  consumption) and I spotted that /home/phablet/.cache/upstart
  /indicator-network.log is being written to rather often (every minute
  or so) (tail -f the log and see what I mean).

  On my phone it the log seems to be being filled with the same 3 types
  of messages over and over:

  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileCountryCode
  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: MobileNetworkCode
  void org::ofono::Interface::NetworkRegistration::_updateProperty(std::string, 
core::dbus::types::Variant): unhandled property change: CellId

  I guess these look like some kind of error message from ofono.  In the
  period of an hour I see ~28K of messages being written, which although
  isn't huge, it is extra work for the system to write and I think the
  messages may need looking into and investigating.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1376302/+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 1376322] [NEW] telepathy-mission-control is spamming dbus.log with error messages

Public bug reported:

I was trying to figure out where excessive file system writes were
coming from (to try to reduce flash writes and hence reduce power
consumption) and I spotted that the dbus log on my phone is being hit by
messages from process 2046:

root@ubuntu-phablet:~# ps -ef | grep 2046
phablet   2046  1741  0 14:43 ?00:00:00 
/usr/lib/telepathy/mission-control-5

root@ubuntu-phablet:~# tail -f /home/phablet/.cache/upstart/dbus.log

(process:2046): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33' is
invalid for instance '0x10af8d8'

(process:2046): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33' is
invalid for instance '0x10af8d8'

(process:2046): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33' is
invalid for instance '0x10af8d8'

(process:2046): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33' is
invalid for instance '0x10af8d8'

(process:2046): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33' is
invalid for instance '0x10af8d8'

..at a rate of ~15K an hour or so.  This is causing unnecessary writes
to the log, filling up file system space and these kind of writes to a
flash file system do cost a small amount of power.  Seems that there is
an error somewhere, else dbus would not be logging it.

** Affects: telepathy-mission-control-5 (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  telepathy-mission-control is spamming dbus.log with error messages

Status in “telepathy-mission-control-5” package in Ubuntu:
  New

Bug description:
  I was trying to figure out where excessive file system writes were
  coming from (to try to reduce flash writes and hence reduce power
  consumption) and I spotted that the dbus log on my phone is being hit
  by messages from process 2046:

  root@ubuntu-phablet:~# ps -ef | grep 2046
  phablet   2046  1741  0 14:43 ?00:00:00 
/usr/lib/telepathy/mission-control-5

  root@ubuntu-phablet:~# tail -f /home/phablet/.cache/upstart/dbus.log

  (process:2046): GLib-GObject-WARNING **:
  /build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33'
  is invalid for instance '0x10af8d8'

  (process:2046): GLib-GObject-WARNING **:
  /build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33'
  is invalid for instance '0x10af8d8'

  (process:2046): GLib-GObject-WARNING **:
  /build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33'
  is invalid for instance '0x10af8d8'

  (process:2046): GLib-GObject-WARNING **:
  /build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33'
  is invalid for instance '0x10af8d8'

  (process:2046): GLib-GObject-WARNING **:
  /build/buildd/glib2.0-2.41.3/./gobject/gsignal.c:3101: signal id '33'
  is invalid for instance '0x10af8d8'

  ..at a rate of ~15K an hour or so.  This is causing unnecessary writes
  to the log, filling up file system space and these kind of writes to a
  flash file system do cost a small amount of power.  Seems that there
  is an error somewhere, else dbus would not be logging it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control-5/+bug/1376322/+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 1308136] Re: telephony-service-indicator is waking up every 4 seconds adding inotifies on paths that don't exist

Yep, still polling at the same rate doing inotify add watches:

root@ubuntu-phablet:~# strace -f  -p 2078
Process 2078 attached with 4 threads
[pid  2091] restart_syscall(<... resuming interrupted call ...> 
[pid  2081] restart_syscall(<... resuming interrupted call ...> 
[pid  2080] restart_syscall(<... resuming interrupted call ...> 
[pid  2078] restart_syscall(<... resuming interrupted call ...> 
[pid  2091] <... restart_syscall resumed> ) = 0
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4118, 702253017}) = 0
[pid  2091] inotify_add_watch(13, "/usr/local/share/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/usr/share/ubuntu-touch/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/etc/xdg/xdg-ubuntu-touch", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4118, 704436632}) = 0
[pid  2091] poll([{fd=12, events=POLLIN}, {fd=13, events=POLLIN}], 2, 3997) = 0 
(Timeout)
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4122, 706523555}) = 0
[pid  2091] inotify_add_watch(13, "/usr/local/share/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/usr/share/ubuntu-touch/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/etc/xdg/xdg-ubuntu-touch", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4122, 708504478}) = 0
[pid  2091] poll([{fd=12, events=POLLIN}, {fd=13, events=POLLIN}], 2, 3992) = 0 
(Timeout)
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4126, 705271171}) = 0
[pid  2091] inotify_add_watch(13, "/usr/local/share/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/usr/share/ubuntu-touch/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] inotify_add_watch(13, "/etc/xdg/xdg-ubuntu-touch", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
[pid  2091] clock_gettime(CLOCK_MONOTONIC, {4126, 706779632}) = 0

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

Title:
  telephony-service-indicator is waking up every 4 seconds adding
  inotifies on paths that don't exist

Status in Telephony Service:
  Triaged
Status in “telephony-service” package in Ubuntu:
  Incomplete

Bug description:
  Daily wakeups tests show that telephony-service-indicator is not that
  idle on an "idle" system:

  http://ci.ubuntu.com/power/eventstat/image/3138/machine/6/task
  /telephony-service-indicator/details/

  It is waking up every 4 seconds on a poll() and doing two
  inotify_add_watch() calls on paths that don't exist, which wastes
  power on devices such as phones, e.g:

  Inotify watches added:
PID  Process  Rate/Sec File
2102 telephony-service-in0.250 /usr/local/share/applications
2102 telephony-service-in0.250 /usr/share/ubuntu-touch/applications

  This can be observed with strace:

  poll([{fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 2, 3984) = 0 (Timeout)
  clock_gettime(CLOCK_MONOTONIC, {10864, 224048956}) = 0
  inotify_add_watch(8, "/usr/local/share/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
  inotify_add_watch(8, "/usr/share/ubuntu-touch/applications", 
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
 = -1 ENOENT (No such file or directory)
  clock_gettime(CLOCK_MONOTONIC, {10864, 229054297}) = 0
  poll([{fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 2, 3987) = 0 (Timeout)
  clo

[Touch-packages] [Bug 1376358] [NEW] lightdm writing the same DEBUG message to /var/log/lightdm/lightdm.log

Public bug reported:

I was trying to figure out where excessive file system writes were
coming from on the ubuntu phone (to try to reduce flash writes and hence reduce 
power
consumption) and I spotted that /var/log/lightdm/lightdm.log is getting the 
same debug message written to every every 300 seconds:

tail -f /var/log/lightdm/lightdm.log
[+5109.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+5409.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+5709.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6009.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6309.64s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6609.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6909.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7209.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7509.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7809.57s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+8109.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed

while this isn't much of a message, it still is causing file system
writes every 5 minutes for the same debug message. Is this necessary?
The fact that it is the same message about the same account and that it
occurs every 300 seconds make me wonder if we can cull this particular
piece of repeated logging.

** Affects: lightdm (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  lightdm writing the same DEBUG message to /var/log/lightdm/lightdm.log

Status in “lightdm” package in Ubuntu:
  New

Bug description:
  I was trying to figure out where excessive file system writes were
  coming from on the ubuntu phone (to try to reduce flash writes and hence 
reduce power
  consumption) and I spotted that /var/log/lightdm/lightdm.log is getting the 
same debug message written to every every 300 seconds:

  tail -f /var/log/lightdm/lightdm.log
  [+5109.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+5409.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+5709.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6009.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6309.64s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6609.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6909.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7209.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7509.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7809.57s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+8109.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed

  while this isn't much of a message, it still is causing file system
  writes every 5 minutes for the same debug message. Is this necessary?
  The fact that it is the same message about the same account and that
  it occurs every 300 seconds make me wonder if we can cull this
  particular piece of repeated logging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1376358/+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 1376357] [NEW] lightdm writing the same DEBUG message to /var/log/lightdm/lightdm.log

Public bug reported:

I was trying to figure out where excessive file system writes were
coming from on the ubuntu phone (to try to reduce flash writes and hence reduce 
power
consumption) and I spotted that /var/log/lightdm/lightdm.log is getting the 
same debug message written to every every 300 seconds:

tail -f /var/log/lightdm/lightdm.log
[+5109.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+5409.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+5709.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6009.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6309.64s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6609.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+6909.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7209.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7509.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+7809.57s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
[+8109.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed

while this isn't much of a message, it still is causing file system
writes every 5 minutes for the same debug message. Is this necessary?
The fact that it is the same message about the same account and that it
occurs every 300 seconds make me wonder if we can cull this particular
piece of repeated logging.

** Affects: lightdm (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  lightdm writing the same DEBUG message to /var/log/lightdm/lightdm.log

Status in “lightdm” package in Ubuntu:
  New

Bug description:
  I was trying to figure out where excessive file system writes were
  coming from on the ubuntu phone (to try to reduce flash writes and hence 
reduce power
  consumption) and I spotted that /var/log/lightdm/lightdm.log is getting the 
same debug message written to every every 300 seconds:

  tail -f /var/log/lightdm/lightdm.log
  [+5109.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+5409.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+5709.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6009.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6309.64s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6609.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+6909.67s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7209.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7509.66s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+7809.57s] DEBUG: User /org/freedesktop/Accounts/User32011 changed
  [+8109.65s] DEBUG: User /org/freedesktop/Accounts/User32011 changed

  while this isn't much of a message, it still is causing file system
  writes every 5 minutes for the same debug message. Is this necessary?
  The fact that it is the same message about the same account and that
  it occurs every 300 seconds make me wonder if we can cull this
  particular piece of repeated logging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1376357/+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 1377854] [NEW] idle phone; polling with 85-195 ms timeouts on poll, possible unneccessary wakeups

2014-10-06 Thread Colin Ian King

Public bug reported:

While trying to figure out what's keeping the phone "busy" when idle
(trying to save power), I noticed that unity8 is performing a lot of
frequent poll() system calls with timeouts of 85-195 ms and it times out
on these the majority of times.Wakeups keep a phone busy, so are
these timeout polls() necessary?

On mako, with a idle phone in the period between inactivity before the
screen blanks I observe:

root@ubuntu-phablet:~# strace -p $(pidof unity8) -e poll
Process 4195 attached
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 98) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 199) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 196) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 195) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 195) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 94) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 89) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 195) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 196) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 188) = 0 (Timeout)

So one can see the poll() in these calls is ~90-195 ms, causing ~5-6
wakeups a second which are poll timeouts. Since no other system calls
are being called, it looks like an inner loop re-polls again for another
timeout to occur again. Perhaps the timeout is too low?

Avoiding excessive wakeups does save power. In this case, it's not much,
but this is the largest cause of wakeups now on an idle phone.

** Affects: unity8 (Ubuntu)
 Importance: Low
 Status: New

** Changed in: unity8 (Ubuntu)
   Importance: Undecided => Low

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

Title:
  idle phone; polling with 85-195 ms timeouts on poll, possible
  unneccessary wakeups

Status in “unity8” package in Ubuntu:
  New

Bug description:
  While trying to figure out what's keeping the phone "busy" when idle
  (trying to save power), I noticed that unity8 is performing a lot of
  frequent poll() system calls with timeouts of 85-195 ms and it times
  out on these the majority of times.Wakeups keep a phone busy, so
  are these timeout polls() necessary?

  On mako, with a idle phone in the period between inactivity before the
  screen blanks I observe:

  root@ubuntu-phablet:~# strace -p $(pidof unity8) -e poll
  Process 4195 attached
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 98) = 0 (Timeout)
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 199) = 0 (Timeout)
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 196) = 0 (Timeout)
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 195) = 0 (Timeout)
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN}, {fd=71, events=POLLIN}, {fd=72, 
events=POLLIN}], 7, 195) = 0 (Timeout)
  poll([{fd=3, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, 
{fd=46, events=POLLIN}, {fd=61, events=POLLIN

[Touch-packages] [Bug 1364368] [NEW] maliit-server has a memory leak

Public bug reported:

I've tracked memory utilisation of maliit-server over a 12 hour period
and can see that the heap is growing at about 1700 bytes a second.   One
can see this by strac'ing the process and seeing glib's malloc
performing 4K mprotects every ~2.4 seconds and the occasional 1MB mmap2
to anonymous memory (aka heap) every 600-620 seconds.

[pid  2708] 12:48:57 mprotect(0xa01fa000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:48:59 mprotect(0xa01fb000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:49:02 mprotect(0xa01fc000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:49:04 mprotect(0xa01fd000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:49:07 mprotect(0xa01fe000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:49:09 mprotect(0xa01ff000, 4096, PROT_READ|PROT_WRITE) = 0
[pid  2708] 12:49:11 mmap2(0xa020, 1048576, PROT_NONE, MAP_PRIVATE|MAP_ANONY
MOUS|MAP_NORESERVE, -1, 0) = 0xa020
[pid  2708] 12:49:11 mprotect(0xa020, 135168, PROT_READ|PROT_WRITE) = 0

Over a period of 1 day this will leak 140MB.

** Affects: maliit-framework (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  maliit-server has a memory leak

Status in “maliit-framework” package in Ubuntu:
  New

Bug description:
  I've tracked memory utilisation of maliit-server over a 12 hour period
  and can see that the heap is growing at about 1700 bytes a second.
  One can see this by strac'ing the process and seeing glib's malloc
  performing 4K mprotects every ~2.4 seconds and the occasional 1MB
  mmap2 to anonymous memory (aka heap) every 600-620 seconds.

  [pid  2708] 12:48:57 mprotect(0xa01fa000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:48:59 mprotect(0xa01fb000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:02 mprotect(0xa01fc000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:04 mprotect(0xa01fd000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:07 mprotect(0xa01fe000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:09 mprotect(0xa01ff000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:11 mmap2(0xa020, 1048576, PROT_NONE, 
MAP_PRIVATE|MAP_ANONY
  MOUS|MAP_NORESERVE, -1, 0) = 0xa020
  [pid  2708] 12:49:11 mprotect(0xa020, 135168, PROT_READ|PROT_WRITE) = 0

  Over a period of 1 day this will leak 140MB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1364368/+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 1364368] Re: maliit-server has a memory leak

To show the heap growth, run:

smemstat -p $(pidof maliit-server) 10

..and one sees ~1640 bytes per second heap growth.

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

Title:
  maliit-server has a memory leak

Status in “maliit-framework” package in Ubuntu:
  New

Bug description:
  I've tracked memory utilisation of maliit-server over a 12 hour period
  and can see that the heap is growing at about 1700 bytes a second.
  One can see this by strac'ing the process and seeing glib's malloc
  performing 4K mprotects every ~2.4 seconds and the occasional 1MB
  mmap2 to anonymous memory (aka heap) every 600-620 seconds.

  [pid  2708] 12:48:57 mprotect(0xa01fa000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:48:59 mprotect(0xa01fb000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:02 mprotect(0xa01fc000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:04 mprotect(0xa01fd000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:07 mprotect(0xa01fe000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:09 mprotect(0xa01ff000, 4096, PROT_READ|PROT_WRITE) = 0
  [pid  2708] 12:49:11 mmap2(0xa020, 1048576, PROT_NONE, 
MAP_PRIVATE|MAP_ANONY
  MOUS|MAP_NORESERVE, -1, 0) = 0xa020
  [pid  2708] 12:49:11 mprotect(0xa020, 135168, PROT_READ|PROT_WRITE) = 0

  Over a period of 1 day this will leak 140MB.

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

This seems to be leaking at the same rate as the leak in bug 1364368, so
it may be a common library that's leaking

-- 
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:
  New

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 1364380] [NEW] unity8-dash is leaking memory at ~1.7K a second

Public bug reported:

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.

** Affects: unity8 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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:
  New

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 1364404] [NEW] qmlscene is leaking ~1.7K per second on an idle application on the phone

Public bug reported:

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.

** Affects: qtdeclarative-opensource-src (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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 1350871] Re: location service is waking up at 10Hz causing possible unwanted wakeups

BTW, which binary blob is the chipset driver?  i don't mind looking at
it and seeing if we can "tweak" it a bit.

-- 
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 1364464] [NEW] unity8-dash has a thread that is polling rather rapidly on epoll wait