[Group.of.nepali.translators] [Bug 1659719] Re: ssh can't call a binary from a snap without the full path

2020-07-14 Thread Launchpad Bug Tracker
This bug was fixed in the package pam - 1.3.1-5ubuntu5

---
pam (1.3.1-5ubuntu5) groovy; urgency=medium

  * debian/libpam-modules.postinst: Add /snap/bin to $PATH in
/etc/environment. (LP: #1659719)

 -- Michael Hudson-Doyle   Fri, 10 Jul 2020
08:35:49 +1200

** Changed in: pam (Ubuntu Groovy)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1659719

Title:
  ssh can't call a binary from a snap without the full path

Status in Snappy:
  Fix Committed
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in openssh package in Ubuntu:
  Confirmed
Status in pam package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  New
Status in openssh source package in Xenial:
  New
Status in pam source package in Xenial:
  New
Status in livecd-rootfs source package in Bionic:
  New
Status in openssh source package in Bionic:
  New
Status in pam source package in Bionic:
  New
Status in livecd-rootfs source package in Focal:
  New
Status in openssh source package in Focal:
  New
Status in pam source package in Focal:
  New
Status in livecd-rootfs source package in Groovy:
  Fix Released
Status in openssh source package in Groovy:
  Confirmed
Status in pam source package in Groovy:
  Fix Released
Status in openssh package in Debian:
  New

Bug description:
  ssh can't call a binary from a snap, it will only work using the full
  path.

  Let's say I have the hello snap installed in 192.168.122.24. Then:

  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello
  elopio@192.168.122.24's password:
  bash: hello: command not found
  elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello
  elopio@192.168.122.24's password:
  Hello, world!

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1659719/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1885503] Re: xenial/linux-aws: 4.4.0-1111.123 -proposed tracker

2020-07-14 Thread Khaled El Mously
No outstanding ADT issues

** Changed in: kernel-sru-workflow/automated-testing
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1885503

Title:
  xenial/linux-aws: 4.4.0-.123 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Fix Released
Status in Kernel SRU Workflow security-signoff series:
  In Progress
Status in Kernel SRU Workflow verification-testing series:
  In Progress
Status in linux-aws source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1885514
  packages:
main: linux-aws
meta: linux-meta-aws
  phase: Testing
  phase-changed: Monday, 06. July 2020 13:01 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
security-signoff: Stalled -- waiting for signoff
verification-testing: Ongoing -- testing in progress
  trackers:
xenial/linux-aws/aws-kernel: bug 1885502
  variant: debs
  versions:
main: 4.4.0-.123
meta: 4.4.0..116

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1885503/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1885508] Re: xenial/linux-raspi2: 4.4.0-1136.145 -proposed tracker

2020-07-14 Thread Khaled El Mously
No outstanding ADT issues

** Changed in: kernel-sru-workflow/automated-testing
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1885508

Title:
  xenial/linux-raspi2: 4.4.0-1136.145 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Invalid
Status in Kernel SRU Workflow security-signoff series:
  In Progress
Status in Kernel SRU Workflow verification-testing series:
  In Progress
Status in linux-raspi2 source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1885514
  packages:
main: linux-raspi2
meta: linux-meta-raspi2
  phase: Testing
  phase-changed: Monday, 06. July 2020 12:36 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
certification-testing: Ongoing -- testing in progress
security-signoff: Stalled -- waiting for signoff
verification-testing: Ongoing -- testing in progress
  trackers:
xenial/linux-raspi2/pi2-kernel: bug 1885507
  variant: debs
  versions:
main: 4.4.0-1136.145
meta: 4.4.0.1136.136

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1885508/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1885510] Re: xenial/linux-snapdragon: 4.4.0-1140.148 -proposed tracker

2020-07-14 Thread Khaled El Mously
No outstanding ADT issues

** Changed in: kernel-sru-workflow/automated-testing
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1885510

Title:
  xenial/linux-snapdragon: 4.4.0-1140.148 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Invalid
Status in Kernel SRU Workflow security-signoff series:
  In Progress
Status in Kernel SRU Workflow verification-testing series:
  In Progress
Status in linux-snapdragon source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1885514
  packages:
main: linux-snapdragon
meta: linux-meta-snapdragon
  phase: Testing
  phase-changed: Monday, 06. July 2020 13:02 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
security-signoff: Stalled -- waiting for signoff
verification-testing: Ongoing -- testing in progress
  trackers:
xenial/linux-snapdragon/dragonboard-kernel: bug 1885509
  variant: debs
  versions:
main: 4.4.0-1140.148
meta: 4.4.0.1140.132

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1885510/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1887037] Re: xenial/linux-gcp: 4.15.0-1080.90~16.04.1 -proposed tracker

2020-07-14 Thread Po-Hsu Lin
4.15.0-1078.88~16.04.1 - gcp
Regression test CMPL, RTB.

Issue to note in gcp:
  ubuntu_k8s_unit_tests - test failed with context package not found in go (bug 
1850105)
  ubuntu_ltp_syscalls - btrfs fill_fs test in fallocate06 (bug 1866323) 
fanotify09 case 3 (bug 1876684) kill11 (bug 1865965) quotactl04 (bug 1854153) 
statx05 (bug 1798524)

Skipped / blacklisted:
 * ubuntu_bpf
 * ubuntu_ltp


** Changed in: kernel-sru-workflow/regression-testing
   Status: In Progress => Fix Released

** Changed in: kernel-sru-workflow/regression-testing
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Po-Hsu Lin 
(cypressyew)

** Tags added: regression-testing-passed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1887037

Title:
  xenial/linux-gcp: 4.15.0-1080.90~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Fix Released
Status in Kernel SRU Workflow security-signoff series:
  In Progress
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux-gcp source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1887038
  packages:
main: linux-gcp
meta: linux-meta-gcp
signed: linux-signed-gcp
  phase: Signoff
  phase-changed: Wednesday, 15. July 2020 03:17 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
security-signoff: Stalled -- waiting for signoff
verification-testing: Ongoing -- testing in progress
  trackers:
xenial/linux-gcp/gcp-kernel: bug 1887035
xenial/linux-gcp/gke-kernel: bug 1887036
  variant: debs
  versions:
main: 4.15.0-1080.90~16.04.1
meta: 4.15.0.1080.82
signed: 4.15.0-1080.90~16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1887037/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1887043] Re: xenial/linux-oracle: 4.15.0-1050.54~16.04.1 -proposed tracker

2020-07-14 Thread Ubuntu Kernel Bot
** Changed in: kernel-sru-workflow/prepare-package
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package
   Status: Fix Committed => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: Fix Committed => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: Fix Committed => Fix Released

** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  kernel-stable-master-bug: 1887044
  packages:
main: linux-oracle
meta: linux-meta-oracle
signed: linux-signed-oracle
- phase: Packaging
- phase-changed: Friday, 10. July 2020 16:10 UTC
+ phase: Building in ppa
+ phase-changed: Wednesday, 15. July 2020 00:07 UTC
  reason:
-   prepare-package: Pending -- tag not published and package not
- uploaded
-   prepare-package-meta: Pending -- tag not published and package not
- uploaded
-   prepare-package-signed: Pending -- tag not published and package not
- uploaded
+   build-packages-ppa: Ongoing -- building in ppa main:building
  replaces: bug 1885809
  variant: debs
+ versions:
+   main: 4.15.0-1050.54~16.04.1
+   meta: 4.15.0.1050.41
+   signed: 4.15.0-1050.54~16.04.1

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1887043

Title:
  xenial/linux-oracle: 4.15.0-1050.54~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-oracle source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1887044
  packages:
main: linux-oracle
meta: linux-meta-oracle
signed: linux-signed-oracle
  phase: Building in ppa
  phase-changed: Wednesday, 15. July 2020 00:07 UTC
  reason:
build-packages-ppa: Ongoing -- building in ppa main:building
  replaces: bug 1885809
  variant: debs
  versions:
main: 4.15.0-1050.54~16.04.1
meta: 4.15.0.1050.41
signed: 4.15.0-1050.54~16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1887043/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1887032] Re: xenial/linux-azure: 4.15.0-1092.102~16.04.1 -proposed tracker

2020-07-14 Thread Ubuntu Kernel Bot
** Changed in: kernel-sru-workflow/prepare-package
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package
   Status: Fix Committed => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: Fix Committed => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: Fix Committed => Fix Released

** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  kernel-stable-master-bug: 1887034
  packages:
main: linux-azure
meta: linux-meta-azure
signed: linux-signed-azure
- phase: Packaging
- phase-changed: Tuesday, 14. July 2020 19:46 UTC
+ phase: Building in ppa
+ phase-changed: Tuesday, 14. July 2020 20:38 UTC
  reason:
-   prepare-package: Pending -- tag not published and package not
- uploaded
-   prepare-package-meta: Pending -- tag not published and package not
- uploaded
-   prepare-package-signed: Pending -- tag not published and package not
- uploaded
+   build-packages-ppa: Ongoing -- building in ppa main:building
  trackers:
xenial/linux-azure/azure-kernel: bug 1887031
  variant: debs
+ versions:
+   main: 4.15.0-1092.102~16.04.1
+   meta: 4.15.0.1092.87
+   signed: 4.15.0-1092.102~16.04.1

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1887032

Title:
  xenial/linux-azure: 4.15.0-1092.102~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow stakeholder-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-azure source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1887034
  packages:
main: linux-azure
meta: linux-meta-azure
signed: linux-signed-azure
  phase: Building in ppa
  phase-changed: Tuesday, 14. July 2020 20:38 UTC
  reason:
build-packages-ppa: Ongoing -- building in ppa main:building
  trackers:
xenial/linux-azure/azure-kernel: bug 1887031
  variant: debs
  versions:
main: 4.15.0-1092.102~16.04.1
meta: 4.15.0.1092.87
signed: 4.15.0-1092.102~16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1887032/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1555338] Re: Linux netfilter IPT_SO_SET_REPLACE memory corruption

2020-07-14 Thread Steve Beattie
** Changed in: linux-flo (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: linux-mako (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: linux-flo (Ubuntu)
   Status: New => Won't Fix

** Changed in: linux-goldfish (Ubuntu)
   Status: New => Won't Fix

** Changed in: linux-mako (Ubuntu)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1555338

Title:
  Linux netfilter IPT_SO_SET_REPLACE memory corruption

Status in linux package in Ubuntu:
  Fix Released
Status in linux-armadaxp package in Ubuntu:
  Invalid
Status in linux-flo package in Ubuntu:
  Won't Fix
Status in linux-goldfish package in Ubuntu:
  Won't Fix
Status in linux-keystone package in Ubuntu:
  Invalid
Status in linux-lts-quantal package in Ubuntu:
  Invalid
Status in linux-lts-raring package in Ubuntu:
  Invalid
Status in linux-lts-saucy package in Ubuntu:
  Invalid
Status in linux-lts-trusty package in Ubuntu:
  Invalid
Status in linux-lts-utopic package in Ubuntu:
  Invalid
Status in linux-lts-vivid package in Ubuntu:
  Invalid
Status in linux-lts-wily package in Ubuntu:
  Invalid
Status in linux-lts-xenial package in Ubuntu:
  Invalid
Status in linux-mako package in Ubuntu:
  Won't Fix
Status in linux-manta package in Ubuntu:
  Invalid
Status in linux-raspi2 package in Ubuntu:
  Fix Released
Status in linux-snapdragon package in Ubuntu:
  Fix Released
Status in linux-ti-omap4 package in Ubuntu:
  Invalid
Status in linux source package in Precise:
  Fix Released
Status in linux-armadaxp source package in Precise:
  Fix Released
Status in linux-flo source package in Precise:
  Invalid
Status in linux-goldfish source package in Precise:
  Invalid
Status in linux-keystone source package in Precise:
  Invalid
Status in linux-lts-quantal source package in Precise:
  Invalid
Status in linux-lts-raring source package in Precise:
  Invalid
Status in linux-lts-saucy source package in Precise:
  Invalid
Status in linux-lts-trusty source package in Precise:
  Fix Released
Status in linux-lts-utopic source package in Precise:
  Invalid
Status in linux-lts-vivid source package in Precise:
  Invalid
Status in linux-lts-wily source package in Precise:
  Invalid
Status in linux-lts-xenial source package in Precise:
  Invalid
Status in linux-mako source package in Precise:
  Invalid
Status in linux-manta source package in Precise:
  Invalid
Status in linux-raspi2 source package in Precise:
  Invalid
Status in linux-snapdragon source package in Precise:
  Invalid
Status in linux-ti-omap4 source package in Precise:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux-armadaxp source package in Trusty:
  Invalid
Status in linux-flo source package in Trusty:
  Invalid
Status in linux-goldfish source package in Trusty:
  Invalid
Status in linux-keystone source package in Trusty:
  Fix Released
Status in linux-lts-quantal source package in Trusty:
  Invalid
Status in linux-lts-raring source package in Trusty:
  Invalid
Status in linux-lts-saucy source package in Trusty:
  Invalid
Status in linux-lts-trusty source package in Trusty:
  Invalid
Status in linux-lts-utopic source package in Trusty:
  Fix Released
Status in linux-lts-vivid source package in Trusty:
  Fix Released
Status in linux-lts-wily source package in Trusty:
  Fix Released
Status in linux-lts-xenial source package in Trusty:
  Fix Released
Status in linux-mako source package in Trusty:
  Invalid
Status in linux-manta source package in Trusty:
  Invalid
Status in linux-raspi2 source package in Trusty:
  Invalid
Status in linux-snapdragon source package in Trusty:
  Invalid
Status in linux-ti-omap4 source package in Trusty:
  Invalid
Status in linux source package in Vivid:
  Fix Released
Status in linux-armadaxp source package in Vivid:
  Invalid
Status in linux-flo source package in Vivid:
  Won't Fix
Status in linux-goldfish source package in Vivid:
  New
Status in linux-keystone source package in Vivid:
  Invalid
Status in linux-lts-quantal source package in Vivid:
  Won't Fix
Status in linux-lts-raring source package in Vivid:
  New
Status in linux-lts-saucy source package in Vivid:
  Won't Fix
Status in linux-lts-trusty source package in Vivid:
  Won't Fix
Status in linux-lts-utopic source package in Vivid:
  Invalid
Status in linux-lts-vivid source package in Vivid:
  Won't Fix
Status in linux-lts-wily source package in Vivid:
  New
Status in linux-lts-xenial source package in Vivid:
  New
Status in linux-mako source package in Vivid:
  Won't Fix
Status in linux-manta source package in Vivid:
  New
Status in linux-raspi2 source package in Vivid:
  Won't Fix
Status in linux-snapdragon source package in Vivid:
  New
Status in linux-ti-omap4 source package in Vivid:
  Invalid
Status in linux source package in Wily:
  Fix Released
Status in 

[Group.of.nepali.translators] [Bug 1555338] Re: Linux netfilter IPT_SO_SET_REPLACE memory corruption

2020-07-14 Thread Steve Beattie
** Changed in: linux-goldfish (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1555338

Title:
  Linux netfilter IPT_SO_SET_REPLACE memory corruption

Status in linux package in Ubuntu:
  Fix Released
Status in linux-armadaxp package in Ubuntu:
  Invalid
Status in linux-flo package in Ubuntu:
  New
Status in linux-goldfish package in Ubuntu:
  New
Status in linux-keystone package in Ubuntu:
  Invalid
Status in linux-lts-quantal package in Ubuntu:
  Invalid
Status in linux-lts-raring package in Ubuntu:
  Invalid
Status in linux-lts-saucy package in Ubuntu:
  Invalid
Status in linux-lts-trusty package in Ubuntu:
  Invalid
Status in linux-lts-utopic package in Ubuntu:
  Invalid
Status in linux-lts-vivid package in Ubuntu:
  Invalid
Status in linux-lts-wily package in Ubuntu:
  Invalid
Status in linux-lts-xenial package in Ubuntu:
  Invalid
Status in linux-mako package in Ubuntu:
  New
Status in linux-manta package in Ubuntu:
  Invalid
Status in linux-raspi2 package in Ubuntu:
  Fix Released
Status in linux-snapdragon package in Ubuntu:
  Fix Released
Status in linux-ti-omap4 package in Ubuntu:
  Invalid
Status in linux source package in Precise:
  Fix Released
Status in linux-armadaxp source package in Precise:
  Fix Released
Status in linux-flo source package in Precise:
  Invalid
Status in linux-goldfish source package in Precise:
  Invalid
Status in linux-keystone source package in Precise:
  Invalid
Status in linux-lts-quantal source package in Precise:
  Invalid
Status in linux-lts-raring source package in Precise:
  Invalid
Status in linux-lts-saucy source package in Precise:
  Invalid
Status in linux-lts-trusty source package in Precise:
  Fix Released
Status in linux-lts-utopic source package in Precise:
  Invalid
Status in linux-lts-vivid source package in Precise:
  Invalid
Status in linux-lts-wily source package in Precise:
  Invalid
Status in linux-lts-xenial source package in Precise:
  Invalid
Status in linux-mako source package in Precise:
  Invalid
Status in linux-manta source package in Precise:
  Invalid
Status in linux-raspi2 source package in Precise:
  Invalid
Status in linux-snapdragon source package in Precise:
  Invalid
Status in linux-ti-omap4 source package in Precise:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux-armadaxp source package in Trusty:
  Invalid
Status in linux-flo source package in Trusty:
  Invalid
Status in linux-goldfish source package in Trusty:
  Invalid
Status in linux-keystone source package in Trusty:
  Fix Released
Status in linux-lts-quantal source package in Trusty:
  Invalid
Status in linux-lts-raring source package in Trusty:
  Invalid
Status in linux-lts-saucy source package in Trusty:
  Invalid
Status in linux-lts-trusty source package in Trusty:
  Invalid
Status in linux-lts-utopic source package in Trusty:
  Fix Released
Status in linux-lts-vivid source package in Trusty:
  Fix Released
Status in linux-lts-wily source package in Trusty:
  Fix Released
Status in linux-lts-xenial source package in Trusty:
  Fix Released
Status in linux-mako source package in Trusty:
  Invalid
Status in linux-manta source package in Trusty:
  Invalid
Status in linux-raspi2 source package in Trusty:
  Invalid
Status in linux-snapdragon source package in Trusty:
  Invalid
Status in linux-ti-omap4 source package in Trusty:
  Invalid
Status in linux source package in Vivid:
  Fix Released
Status in linux-armadaxp source package in Vivid:
  Invalid
Status in linux-flo source package in Vivid:
  Won't Fix
Status in linux-goldfish source package in Vivid:
  New
Status in linux-keystone source package in Vivid:
  Invalid
Status in linux-lts-quantal source package in Vivid:
  Won't Fix
Status in linux-lts-raring source package in Vivid:
  New
Status in linux-lts-saucy source package in Vivid:
  Won't Fix
Status in linux-lts-trusty source package in Vivid:
  Won't Fix
Status in linux-lts-utopic source package in Vivid:
  Invalid
Status in linux-lts-vivid source package in Vivid:
  Won't Fix
Status in linux-lts-wily source package in Vivid:
  New
Status in linux-lts-xenial source package in Vivid:
  New
Status in linux-mako source package in Vivid:
  Won't Fix
Status in linux-manta source package in Vivid:
  New
Status in linux-raspi2 source package in Vivid:
  Won't Fix
Status in linux-snapdragon source package in Vivid:
  New
Status in linux-ti-omap4 source package in Vivid:
  Invalid
Status in linux source package in Wily:
  Fix Released
Status in linux-armadaxp source package in Wily:
  Invalid
Status in linux-flo source package in Wily:
  New
Status in linux-goldfish source package in Wily:
  New
Status in linux-keystone source package in Wily:
  Invalid
Status in linux-lts-quantal source package in Wily:
  Invalid
Status in 

[Group.of.nepali.translators] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-07-14 Thread Launchpad Bug Tracker
This bug was fixed in the package libseccomp - 2.4.3-1ubuntu4

---
libseccomp (2.4.3-1ubuntu4) groovy; urgency=medium

  * d/p/db-consolidate-some-of-the-code-which-adds-rules.patch
  * d/p/db-add-shadow-transactions.patch (LP: #1861177)
Backport upstream patches to address performance regression introduced
in libseccomp 2.4.

 -- Ioanna Alifieraki   Mon, 22
Jun 2020 11:10:27 +0100

** Changed in: libseccomp (Ubuntu Groovy)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1861177

Title:
  seccomp_rule_add is very slow

Status in snapd:
  Invalid
Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [IMPACT]
  There is a known and patched issue with version 2.4 of libseccomp where 
certain operations have a large performance regression. This is causing some 
packages that use libseccomp such as container orchestration systems to 
occasionally time out or otherwise fail under certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

  Upstream issue : https://github.com/seccomp/libseccomp/issues/153
  Upstream fix : https://github.com/seccomp/libseccomp/pull/180/

  [Test Case]

  For this test case we use Docker on Ubuntu Groovy (20.10) :

  --> Current libseccomp version
  #dpkg -l | grep libseccomp
  ii  libseccomp2:amd64  2.4.3-1ubuntu3 
 amd64high level interface to Linux seccomp filter

  ## pull ubuntu image
  # docker pull ubuntu
  ## create a container
  # docker run --name test_seccomp -it 74435f89ab78 /bin/bash

  ## run test case
  # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done
  ...
  MAX TIME :
  real  0m10,319s
  user  0m0,018s
  sys   0m0,033s

  
  --> Patched libseccomp version

  # dpkg -l | grep libseccomp
  ii  libseccomp2:amd64  2.4.3-1ubuntu4 
 amd64high level interface to Linux seccomp filter

  # docker start test_seccomp
  ## run test case
  # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done
  ...
  MAX TIME :
  real  0m3,650s
  user  0m0,025s
  sys   0m0,028s

  [Regression Potential]

  The first of the 2 patches cleans up the code that adds rules to a
  single filter without changing the logic of the code. The second patch
  introduces the idea of shadow transactions. On a successful
  transaction commit the old transaction checkpoint is preserved and is
  brought up to date with the current filter. The next time a new
  transaction starts, it checks is the a shadow transaction exist and if
  so the shadow is used instead of creating a new checkpoint from
  scratch [1]. This is the patch that mitigates the performance
  regression. Any potential regression will involve the parts of the
  code that add rules to filters and/or the code that creates and checks
  the shadow transactions.

  
  [Other]

  Affected releases : Groovy, Focal, Eoan, Bionic, Xenial.

  [1]
  
https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1861177/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1724614] Re: [KVM] Lower the default for halt_poll_ns to 200000 ns

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu Xenial)
   Status: New => Fix Released

** No longer affects: linux (Ubuntu Groovy)

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1724614

Title:
  [KVM] Lower the default for halt_poll_ns to 20 ns

Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Won't Fix

Bug description:
  [Environment]

  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  Codename: xenial

  Linux porygon 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36
  UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

  [Description]

  We've identified a constant high (~90%) system time load at the host level
  when a VCPU in a KVM guest remains or switches/resumes in/from halt/idle state
  in a constant frequency, usually for a slightly smaller time than the default 
polling
  period.

  The halt polling mechanism has the intention to reduce latency in the cases
  on which the guest is quickly resumed saving a call to the scheduler.

  We've performed some testing by adjusting the 
/sys/module/kvm/parameters/halt_poll_ns
  value which defines the max time that should be spend polling before calling 
the
  scheduler to allow it to run other tasks (which defaults to 40 ns in 
Ubuntu).

  With the default value the tests shows that the load remains nearly on 90% on 
a
  VCPU that has a single task in the run queue.

  We've also tested altering the halt_poll_ns value to 20 ns and the results
  seems to drop the system time usage from 90% to ~25%.

  root@porygon:/home/ubuntu# echo 20 > 
/sys/module/kvm/parameters/halt_poll_ns
  root@porygon:/home/ubuntu# mpstat 1 -P 6 5
  Linux 4.4.0-112-generic (porygon) 01/24/2018  _x86_64_(64 CPU)

  02:06:08 PM  CPU  %usr  %nice  %sys %iowait  %irq   %soft  %steal  %guest  
%gnice   %idle
  02:06:09 PM6  0.00  0.00   4.85  0.000.000.000.00   16.50
0.00   78.64
  [...]
  Average:   6  0.00  0.00   4.26  0.000.000.000.00   17.83
0.00   77.91

  
  root@porygon:/home/ubuntu# echo 40 > 
/sys/module/kvm/parameters/halt_poll_ns
  root@porygon:/home/ubuntu# mpstat 1 -P 6 5
  Linux 4.4.0-112-generic (porygon) 01/24/2018  _x86_64_(64 CPU)

  02:06:20 PM  CPU  %usr  %nice  %sys %iowait   %irq   %soft  %steal  %guest  
%gnice   %idle
  02:06:21 PM6  0.00  0.00   87.13  0.000.000.000.00   11.88
0.000.99
  [...]
  Average:   6  0.00  0.00   89.59  0.000.000.000.008.45
0.001.96

  [Reproducer]

  1) Configure a KVM guest with a single pinned VCPU.
  2) Run the following program (http://pastebin.ubuntu.com/25731919/) at the 
KVM guest.
  $ gcc test.c -lpthread -o test && ./test 250 0
  3) Run mpstat at the host on the pinned CPU and compare the stats
  $ sudo mpstat 1 -P 6 5

  [Fix]

  Change the halt polling max time to half of the current value.

  In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to
  increase heavily even in cases where the performance improvement was
  small.  In particular, bandwidth divided by CPU usage was as much as
  60% lower.

  To some extent this is the expected effect of the patch, and the
  additional CPU utilization is only visible when running the
  benchmarks.  However, halving the threshold also halves the extra
  CPU utilization (from +30-130% to +20-70%) and has no negative
  effect on performance.

  Signed-off-by: Paolo Bonzini 

  *
  
https://github.com/torvalds/linux/commit/b401ee0b85a53e89739ff68a5b1a0667d664afc9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/xenial/+source/linux/+bug/1724614/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1887028] Re: xenial/linux-aws-hwe: 4.15.0-1079.83~16.04.1 -proposed tracker

2020-07-14 Thread Ubuntu Kernel Bot
** Changed in: kernel-sru-workflow/prepare-package
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package
   Status: Fix Committed => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: In Progress => Fix Committed

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: Fix Committed => Fix Released

** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  kernel-stable-master-bug: 1887029
  packages:
main: linux-aws-hwe
meta: linux-meta-aws-hwe
- phase: Packaging
- phase-changed: Friday, 10. July 2020 15:31 UTC
+ phase: Building in ppa
+ phase-changed: Tuesday, 14. July 2020 15:58 UTC
  reason:
-   prepare-package: Stalled -- package not uploaded
-   prepare-package-meta: Stalled -- package not uploaded
+   build-packages-ppa: Ongoing -- building in ppa main:building
  replaces: bug 1885794
  variant: debs
  versions:
main: 4.15.0-1079.83~16.04.1
meta: 4.15.0.1079.76

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1887028

Title:
  xenial/linux-aws-hwe: 4.15.0-1079.83~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-aws-hwe source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1887029
  packages:
main: linux-aws-hwe
meta: linux-meta-aws-hwe
  phase: Building in ppa
  phase-changed: Tuesday, 14. July 2020 15:58 UTC
  reason:
build-packages-ppa: Ongoing -- building in ppa main:building
  replaces: bug 1885794
  variant: debs
  versions:
main: 4.15.0-1079.83~16.04.1
meta: 4.15.0.1079.76

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1887028/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1724614] Re: [KVM] Lower the default for halt_poll_ns to 200000 ns

2020-07-14 Thread Guilherme G. Piccoli
** No longer affects: linux (Ubuntu)

** No longer affects: linux (Ubuntu Xenial)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1724614

Title:
  [KVM] Lower the default for halt_poll_ns to 20 ns

Status in linux source package in Zesty:
  Won't Fix
Status in linux source package in Groovy:
  New

Bug description:
  [Environment]

  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  Codename: xenial

  Linux porygon 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36
  UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

  [Description]

  We've identified a constant high (~90%) system time load at the host level
  when a VCPU in a KVM guest remains or switches/resumes in/from halt/idle state
  in a constant frequency, usually for a slightly smaller time than the default 
polling
  period.

  The halt polling mechanism has the intention to reduce latency in the cases
  on which the guest is quickly resumed saving a call to the scheduler.

  We've performed some testing by adjusting the 
/sys/module/kvm/parameters/halt_poll_ns
  value which defines the max time that should be spend polling before calling 
the
  scheduler to allow it to run other tasks (which defaults to 40 ns in 
Ubuntu).

  With the default value the tests shows that the load remains nearly on 90% on 
a
  VCPU that has a single task in the run queue.

  We've also tested altering the halt_poll_ns value to 20 ns and the results
  seems to drop the system time usage from 90% to ~25%.

  root@porygon:/home/ubuntu# echo 20 > 
/sys/module/kvm/parameters/halt_poll_ns
  root@porygon:/home/ubuntu# mpstat 1 -P 6 5
  Linux 4.4.0-112-generic (porygon) 01/24/2018  _x86_64_(64 CPU)

  02:06:08 PM  CPU  %usr  %nice  %sys %iowait  %irq   %soft  %steal  %guest  
%gnice   %idle
  02:06:09 PM6  0.00  0.00   4.85  0.000.000.000.00   16.50
0.00   78.64
  [...]
  Average:   6  0.00  0.00   4.26  0.000.000.000.00   17.83
0.00   77.91

  
  root@porygon:/home/ubuntu# echo 40 > 
/sys/module/kvm/parameters/halt_poll_ns
  root@porygon:/home/ubuntu# mpstat 1 -P 6 5
  Linux 4.4.0-112-generic (porygon) 01/24/2018  _x86_64_(64 CPU)

  02:06:20 PM  CPU  %usr  %nice  %sys %iowait   %irq   %soft  %steal  %guest  
%gnice   %idle
  02:06:21 PM6  0.00  0.00   87.13  0.000.000.000.00   11.88
0.000.99
  [...]
  Average:   6  0.00  0.00   89.59  0.000.000.000.008.45
0.001.96

  [Reproducer]

  1) Configure a KVM guest with a single pinned VCPU.
  2) Run the following program (http://pastebin.ubuntu.com/25731919/) at the 
KVM guest.
  $ gcc test.c -lpthread -o test && ./test 250 0
  3) Run mpstat at the host on the pinned CPU and compare the stats
  $ sudo mpstat 1 -P 6 5

  [Fix]

  Change the halt polling max time to half of the current value.

  In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to
  increase heavily even in cases where the performance improvement was
  small.  In particular, bandwidth divided by CPU usage was as much as
  60% lower.

  To some extent this is the expected effect of the patch, and the
  additional CPU utilization is only visible when running the
  benchmarks.  However, halving the threshold also halves the extra
  CPU utilization (from +30-130% to +20-70%) and has no negative
  effect on performance.

  Signed-off-by: Paolo Bonzini 

  *
  
https://github.com/torvalds/linux/commit/b401ee0b85a53e89739ff68a5b1a0667d664afc9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/zesty/+source/linux/+bug/1724614/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1869948] Re: Multiple Kexec in AWS Nitro instances fail

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** No longer affects: linux (Ubuntu Disco)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1869948

Title:
  Multiple Kexec in AWS Nitro instances fail

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in linux source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Currently, users cannot perform multiple kernel kexec loads on AWS Nitro 
instances (KVM-based); after the 2nd or 3rd kexec, an initrd corruption is 
observed, with the following signature:

   Initramfs unpacking failed: junk within compressed archive
  [...]
   Kernel panic - not syncing: No working init found.
  Try passing init= option to kernel. See Linux 
Documentation/admin-guide/init.rst for guidance.
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc7-gpiccoli+ #26  Hardware 
name: Amazon EC2 t3.large/, BIOS 1.0 10/16/2017
  Call Trace:
dump_stack+0x6d/0x9a
? csum_partial_copy_generic+0x150/0x170
panic+0x101/0x2e3
? do_execve+0x25/0x30
? rest_init+0xb0/0xb0
kernel_init+0xfb/0x100
ret_from_fork+0x35/0x40

  * After investigation (see comment 2), it was noticed the Amazon ena
  network driver doesn't provide a shutdown() handler, hence it could be
  performing a DMA transaction to a previous valid address during boot,
  which would then corrupt kernel memory. The following patch was
  proposed and fixed the issue, allowing 1000 kexecs to be executed
  successfully with no issues observed: 428c491332bc("net: ena: Add PCI
  shutdown handler to allow safe kexec") [
  git.kernel.org/linus/428c491332bc ].

  * Hence, we are hereby requesting SRU for this patch. It was tested in
  all supported series (4.4, 4.15 and 5.3) in Amazon Nitro instances
  with success, and reviewed/acked by ena driver team and a kexec
  developer from other distro. Worth mentioning that we proposed an
  upstream multi-vendor discussion about this issue:
  marc.info/?l=kexec=158299605013194

  [Test case]

  * The basic test procedure is about performing multiple kexecs
  sequentially; AWS does not provide a full console, so in case of
  failures one could check the instance screenshot or use pstore/ramoops
  in order to collect dmesg after a crash in a preserved memory area.
  The commands used to perform kexec are:

  kexec -l  --initrd  --reuse-cmdline
  systemctl kexec

  Alternatively, one could user "--append=" instead of "--reuse-cmdline"
  if a change in kexec command-line is desired; also, to execute the
  kexec-loaded kernel both "kexec -e" and "systemctl kexec" are equally
  valid.

  * On comment 3 we proposed a script/approach to auto-test kexecs, used
  here to perform 1000 kexecs with the proposed patch.

  [Regression Potential]

  * Although the patch proposed here introduce a PCI handler, it kept
  the remove handler identical and based shutdown strongly on
  ena_remove(), changing just netdev handling following other upstream
  drivers. It was extensively tested and presented no issue. Also, it's
  self-contained and affect only one driver, so any other cloud
  providers or non-cloud environment wouldn't be even affected by the
  patch.

  * In case of a potential regression, it could manifest as a delay or
  issue on reboot/shutdown path, only if ena driver is in use.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1794877] Re: Crash in ixgbe, during tx packet xmit (while potentially changing queues number)

2020-07-14 Thread Guilherme G. Piccoli
We couldn't reproduce the bug and reporter cannot help in providing data, so 
we're marking as invalid. If anybody ever reproduces that, please ping here and 
reopen.
Thanks,


Guilherme

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

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1794877

Title:
  Crash in ixgbe, during tx packet xmit (while potentially changing
  queues number)

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Invalid

Bug description:
  It was reported that ixgbe driver may crash with the following stack
  trace, while changing interrupt/queue configuration (probably using
  ethtool --set-channel):

  [28661.949147] init: irqbalance main process (19397) killed by TERM signal 
  [28662.381154] ixgbe :04:00.0: removed PHC on eth4 
  [28662.502142] ixgbe :04:00.0: Multiqueue Enabled: Rx Queue count = 18, 
Tx Queue count = 18 
  [28662.588634] ixgbe :04:00.0: registered PHC device on eth4 
  [28662.689789] br-iscsi-left: port 1(eth4.4011) entered disabled state 
  [28662.689951] br-sio-bel: port 1(eth4.4015) entered disabled state 
  [28662.690039] br-sio-fel: port 1(eth4.4017) entered disabled state 
  [28662.694227] ixgbe :04:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX 
  [28662.694506] br-iscsi-left: port 1(eth4.4011) entered forwarding state 
  [28662.694519] br-iscsi-left: port 1(eth4.4011) entered forwarding state 
  [28662.694596] br-sio-bel: port 1(eth4.4015) entered forwarding state 
  [28662.694604] br-sio-bel: port 1(eth4.4015) entered forwarding state 
  [28662.694651] br-sio-fel: port 1(eth4.4017) entered forwarding state 
  [28662.694658] br-sio-fel: port 1(eth4.4017) entered forwarding state 
  [28662.709921] ixgbe :04:00.1: removed PHC on eth5 
  [28662.834289] ixgbe :04:00.1: Multiqueue Enabled: Rx Queue count = 18, 
Tx Queue count = 18 
  [28662.915121] ixgbe :04:00.1: registered PHC device on eth5 
  [28663.018209] ixgbe :04:00.1 eth5: NIC Link is Up 10 Gbps, Flow Control: 
RX/TX 
  [28663.018356] BUG: unable to handle kernel NULL pointer dereference at 
0058 
  [28663.026266] IP: [] ixgbe_xmit_frame_ring+0x81/0xf50 
[ixgbe] 
  [28663.033491] PGD 800046bcc067 PUD 46bcd067 PMD 0 
  [28663.038562] Oops:  [#1] SMP 
  [28663.328921] Call Trace: 
  [28663.334598]  
  [28663.336551] [] ixgbe_xmit_frame+0x42/0x90 [ixgbe] 
  [28663.349627] [] dev_hard_start_xmit+0x23d/0x400 
  [28663.358854] [] sch_direct_xmit+0xe4/0x1f0 
  [28663.367602] [] __qdisc_run+0x9b/0x1c0 
  [28663.376110] [] net_tx_action+0x15e/0x240 
  [28663.384673] [] __do_softirq+0xe6/0x2a0 
  [28663.392944] [] irq_exit+0x95/0xa0 
  [28663.400720] [] do_IRQ+0x56/0xe0 
  [28663.408338] [] common_interrupt+0xbf/0xbf 
  [28663.416733]  
  [28663.418680] [] ? worker_thread+0x18c/0x480 
  [28663.430363] [] ? rescuer_thread+0x310/0x310 
  [28663.438870] [] kthread+0xd8/0xf0 
  [28663.446368] [] ? kthread_park+0x60/0x60 
  [28663.454385] [] ret_from_fork+0x55/0x80 
  [28663.462286] [] ? kthread_park+0x60/0x60 
  [28663.470488] Code: 2a 41 83 e8 01 31 c0 45 0f b7 c0 49 83 c0 01 49 c1 e0 04 
8b 74 07 3c 48 83 c0 10 8d 96 ff 3f 00 00 c1 ea 0e 01 d1 4c 39 c0 75 e8 <0f> b7 
43 58 0f b7 73 5a 83 c1 03 31 d2 66 39 f0 66 0f 43 53 54 
  [28663.498992] RIP [] ixgbe_xmit_frame_ring+0x81/0xf50 
[ixgbe] 
  [28663.512112] RSP  
  [28663.518217] CR2: 0058

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1816743] Re: Add systemd's kdump service command-line regardless if user provides or not KDUMP_CMDLINE_APPEND

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: makedumpfile (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

** No longer affects: makedumpfile (Ubuntu Cosmic)

** No longer affects: makedumpfile (Ubuntu Disco)

** Also affects: makedumpfile (Ubuntu Groovy)
   Importance: Low
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1816743

Title:
  Add systemd's kdump service command-line regardless if user provides
  or not KDUMP_CMDLINE_APPEND

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Eoan:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed

Bug description:
  Since Xenial release, Ubuntu relies on systemd as its init system -
  there's a kdump service to prevent some other services to
  unnecessarily start in kdump environment.

  Problem: if we add something to KDUMP_CMDLINE_APPEND, the entry for
  kdump service, "systemd.unit=kdump-tools.service" is removed from the
  command-line. The user manually needs to add that, and this seems
  highly prone to error.

  We propose here to decouple the "systemd.unit=kdump-tools.service"
  parameter from KDUMP_CMDLINE_APPEND, so if user wants really to remove
  this option, they should used KDUMP_CMDLINE instead.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1800562] Re: Remove obsolete "nousb" option in kdump command-line for newer kernels

2020-07-14 Thread Guilherme G. Piccoli
** No longer affects: makedumpfile (Ubuntu Cosmic)

** No longer affects: makedumpfile (Ubuntu Disco)

** Also affects: makedumpfile (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: makedumpfile (Ubuntu Groovy)
   Importance: High
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Changed in: makedumpfile (Ubuntu Focal)
   Status: New => Confirmed

** Changed in: makedumpfile (Ubuntu Eoan)
   Status: In Progress => Confirmed

** Changed in: makedumpfile (Ubuntu Groovy)
   Status: In Progress => Confirmed

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

** Changed in: makedumpfile (Ubuntu Groovy)
   Importance: High => Medium

** Changed in: makedumpfile (Ubuntu Eoan)
   Importance: High => Medium

** Changed in: makedumpfile (Ubuntu Bionic)
   Importance: High => Medium

** Changed in: makedumpfile (Ubuntu Xenial)
   Importance: High => Medium

** Changed in: makedumpfile (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1800562

Title:
  Remove obsolete "nousb" option in kdump command-line for newer kernels

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Eoan:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed

Bug description:
  [Impact]
  * Kdump command-line include an obsolete "nousb" parameter by default, which 
can cause a misimpression: users will think they are not booting with USB, but 
they are.

  * Since kernel v4.5, the correct parameter to disable USB subsystem
  initialization is "usbcore.nousb" always (instead of "nousb" in case
  the subsystem is built-in). This was changed by commit 097a9ea0e48
  ("usb: make "nousb" a clear module parameter").

  * USB may be pretty essential in case for example kdump users need to
  decrypt a disk under LUKS, and there's only an USB keyboard connected
  to the system. Given the option is innocuous since Bionic, we should
  just drop it to prevent confusion.

  
  [Test Case]

  1) Deploy a Disco VM e.g. with uvt-kvm
  2) Install the kdump-tools package
  3) Run `kdump-config test`and check for the 'nousb' parameter:

  $ kdump-config test
  ...
  kexec command to be used:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic 
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" 
/var/lib/kdump/vmlinuz

  
  [Regression Potential]

  The regression potential is extremely low, since the "nousb" parameter
  is not used since Bionic although is there. Any bugs we would have by
  changing this are still valid by not removing the option - the
  semantics with or without "nosub" is the same since from Bionic.

  NOTICE we won't change Xenial, it can use kernel 4.4 which indeed
  disables USB by taking the "nousb" parameter.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1800873] Re: Add KDUMP_CMDLINE_REMOVE option to remove portions of kernel command-line

2020-07-14 Thread Guilherme G. Piccoli
** No longer affects: makedumpfile (Ubuntu Trusty)

** Changed in: makedumpfile (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

** No longer affects: makedumpfile (Ubuntu Cosmic)

** No longer affects: makedumpfile (Ubuntu Disco)

** Also affects: makedumpfile (Ubuntu Groovy)
   Importance: Low
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: Confirmed

** Also affects: makedumpfile (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: makedumpfile (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: makedumpfile (Ubuntu Eoan)
   Status: New => Confirmed

** Changed in: makedumpfile (Ubuntu Focal)
   Status: New => Confirmed

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

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

** Changed in: makedumpfile (Ubuntu Eoan)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: makedumpfile (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1800873

Title:
  Add KDUMP_CMDLINE_REMOVE option to remove portions of kernel command-
  line

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Eoan:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed

Bug description:
  Currently kdump has an useful option to append parameters to the kdump
  kernel command-line, "KDUMP_CMDLINE_APPEND". Would be useful to have a
  reciprocal option which users could use to remove parameters without
  needing to rewrite the whole line.

  The option name proposed here is KDUMP_CMDLINE_REMOVE, which would
  tentatively "sed"-out the options from the kernel command-line before
  appending the new ones from KDUMP_CMDLINE_APPEND.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1851663] Re: Consistent autopkgtest failures on ppc64el/s390x

2020-07-14 Thread Guilherme G. Piccoli
** No longer affects: makedumpfile (Ubuntu Disco)

** Also affects: makedumpfile (Ubuntu Groovy)
   Importance: Medium
 Assignee: Thadeu Lima de Souza Cascardo (cascardo)
   Status: Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1851663

Title:
  Consistent autopkgtest failures on ppc64el/s390x

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Xenial:
  Confirmed
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Eoan:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed

Bug description:
  Recently autopkgtest started to consistently fail in ppc64el / s390x.
  When testing manually, the kernel dump is collected and all works
  fine. By discussing with the package maintainer (Cascardo), it seems
  it started after a change in the instance type of the tests, to
  m1.large.

  This seems either a problem in the test infrastructure itself or a likely a 
"timing" problem in the test (i.e., requiring some pause or delay that is not 
currently enough).
  This demands investigation because those failures delay the package release 
for all arches, usually those releases contain important fixes.

  Also, the recurrent "workaround" is to mark the tests as "force-
  badtest" in ubuntu-hints for the 2 arches, which is in practice
  skipping the test, so those 2 arches are getting releases untested by
  the automatic infrastructure.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1845048] Re: Improve sysctl handling on kdump-tools

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: makedumpfile (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: makedumpfile (Ubuntu Xenial)
   Status: Confirmed => Opinion

** Changed in: makedumpfile (Ubuntu Bionic)
   Status: Confirmed => In Progress

** Changed in: makedumpfile (Ubuntu Eoan)
   Status: Confirmed => In Progress

** Changed in: makedumpfile (Ubuntu Focal)
   Status: Confirmed => In Progress

** Also affects: makedumpfile (Ubuntu Groovy)
   Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Tags added: sts

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1845048

Title:
  Improve sysctl handling on kdump-tools

Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  Opinion
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Groovy:
  In Progress
Status in makedumpfile package in Debian:
  New

Bug description:
  [impact]

  Documentation, and past behavior, for kdump-tools was that the
  KDUMP_SYSCTL variable in the /etc/default/kdump-tools file would be
  applied to the system kernel params at kdump 'load'.  However this is
  no longer true, and those params are no longer applied to the system's
  kernel param settings.

  [test case]

  install linux-crashdump (and kdump-tools).

  Edit the /etc/default/kdump-tools file to set the KDUMP_SYSCTL param
  to something other than default, e.g.:

  KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"

  reboot, or unload/reload kdump, to pick up the changes to the file.

  Check if the panic_on_warn param is set:

  $ cat /proc/sys/kernel/panic_on_warn
  0

  the problem does not seem to be with sysctl, as manually calling it
  does work:

  $ KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"
  $ cat /proc/sys/kernel/panic_on_warn
  0
  $ sudo sysctl -w $KDUMP_SYSCTL
  kernel.panic_on_oops = 1
  kernel.panic_on_warn = 1
  $ cat /proc/sys/kernel/panic_on_warn
  1

  [regression potential]

  TBD

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1807393] Re: nvme - Polling on timeout

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1807393

Title:
  nvme - Polling on timeout

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  [Impact]
  * NVMe controllers potentially could miss to send an interrupt, specially
  due to bugs in virtual devices(which are common those days - qemu has its
  own NVMe virtual device, so does AWS). This would be a difficult to
  debug situation, because NVMe driver only reports the request timeout,
  not the reason.

  * The upstream patch proposed to SRU here here, 7776db1ccc12
  ("NVMe/pci: Poll CQ on timeout") was designed to provide more information
  in these cases, by pro-actively polling the CQEs on request timeouts, to
  check if the specific request was completed and some issue (probably a
  missed interrupt) prevented the driver to notice, or if the request really
  wasn't completed, which indicates more severe issues.

  * Although quite useful for debugging, this patch could help to mitigate
  issues in cloud environments like AWS, in case we may have jitter in
  request completion and the i/o timeout was set to low values, or even
  in case of atypical bugs in the virtual NVMe controller. With this patch,
  if polling succeeds the NVMe driver will continue working instead of
  trying a reset controller procedure, which may lead to fails in the 
  rootfs - refer to https://launchpad.net/bugs/1788035.

  
  [Test Case]

  * It's a bit tricky to artificially create a situation of missed interrupt;
  one idea was to implement a small hack in the NVMe qemu virtual device
  that given a trigger in guest kernel, will induce the virtual device to
  skip an interrupt. The hack patch is present in comment #1 below.

  * To trigger such hack from guest kernel, all is needed is to issue a
  raw admin command from nvme-cli: "nvme admin-passthru -o 0xff /dev/nvme0"
  After that, just perform some I/Os to see one of them aborting - one could
  use dd for this goal, like "dd if=/dev/zero of=/dev/nvme0n1 count=5".

  
  [Regression Potential]

  * There are no clear risks in adding such polling mechanism to the NVMe 
driver; one bad thing that was neverreported but could happen with this patch 
is the device could be in a bad state IRQ-wise that a reset would fix, but
  the patch could cause all requests to be completed via polling, which
  prevents the adapter reset. This is however a very hypothetical situation,
  which would also happen in the mainline kernel (since it has the patch).

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1764956] Re: Guests using IBRS incur a large performance penalty

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: linux (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Trusty)
 Assignee: (unassigned) => Gavin Guo (mimi0213kimo)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1764956

Title:
  Guests using IBRS incur a large performance penalty

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  [Impact]
  the IBRS would be mistakenly enabled in the host when the switching
  from an IBRS-enabled VM and that causes the performance overhead in
  the host. The other condition could also mistakenly disables the IBRS
  in VM when context-switching from the host. And this could be
  considered a CVE host.

  [Fix]
  The patch fixes the logic inside the x86_virt_spec_ctrl that it checks
  the ibrs_enabled and _or_ the hostval with the SPEC_CTRL_IBRS as the
  x86_spec_ctrl_base by default is zero. Because the upstream
  implementation is not equal to the Xenial's implementation. Upstream
  doesn't use the IBRS as the formal fix. So, by default, it's zero.

  On the other hand, after the VM exit, the SPEC_CTRL register also
  needs to be saved manually by reading the SPEC_CTRL MSR as the MSR
  intercept is disabled by default in the hardware_setup(v4.4) and
  vmx_init(v3.13). The access to SPEC_CTRL MSR in VM is direct and
  doesn't trigger a trap. So, the vmx_set_msr() function isn't called.

  The v3.13 kernel hasn't been tested. However, the patch can be viewed
  at:
  
http://kernel.ubuntu.com/git/gavinguo/ubuntu-trusty-amd64.git/log/?h=sf00191076-sru

  The v4.4 patch:
  
http://kernel.ubuntu.com/git/gavinguo/ubuntu-xenial.git/log/?h=sf00191076-spectre-v2-regres-backport-juerg

  [Test]

  The patch has been tested on the 4.4.0-140.166 and works fine.

  The reproducing environment:
  Guest kernel version: 4.4.0-138.164
  Host kernel version: 4.4.0-140.166

  (host IBRS, guest IBRS)

  - 1). (0, 1).
  The case can be reproduced by the following instructions:
  guest$ echo 1 | sudo tee /proc/sys/kernel/ibrs_enabled
  1

  

  host$ cat /proc/sys/kernel/ibrs_enabled
  0
  host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done
  110001001010

  Some of the IBRS bit inside the SPEC_CTRL MSR are mistakenly
  enabled.

  host$ taskset -c 5 stress-ng -c 1 --cpu-ops 2500
  stress-ng: info:  [11264] defaulting to a 86400 second run per stressor
  stress-ng: info:  [11264] dispatching hogs: 1 cpu
  stress-ng: info:  [11264] cache allocate: default cache size: 35840K
  stress-ng: info:  [11264] successful run completed in 33.48s

  The host kernel didn't notice the IBRS bit is enabled. So, the situation
  is the same as "echo 2 > /proc/sys/kernel/ibrs_enabled" in the host.
  And running the stress-ng is a pure userspace CPU capability
  calculation. So, the performance downgrades to about 1/3. Without the
  IBRS enabled, it needs about 10s.

  - 2). (1, 1) disables IBRS in host -> (0, 1) actually it becomes (0, 0).
  The guest IBRS has been mistakenly disabled.

  guest$ echo 2 | sudo tee /proc/sys/kernel/ibrs_enabled
  guest$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done
  

  host$ echo 2 | sudo tee /proc/sys/kernel/ibrs_enabled
  host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done
  
  host$ echo 0 | sudo tee /proc/sys/kernel/ibrs_enabled
  host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done
  

  guest$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done
  

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1814095] Re: bnxt_en_po: TX timed out triggering Netdev Watchdog Timer

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Nivedita Singhvi (niveditasinghvi)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1814095

Title:
  bnxt_en_po: TX timed out triggering Netdev Watchdog Timer

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  The bnxt_en_bpo driver experienced tx timeouts causing the system to
  experience network stalls and fail to send data and heartbeat packets.

  The following 25Gb Broadcom NIC error was seen on Xenial
  running the 4.4.0-141-generic kernel on an amd64 host
  seeing moderate-heavy network traffic (just once):

  * The bnxt_en_po driver froze on a "TX timed out" error
    and triggered the Netdev Watchdog timer under load.

  * From kernel log:
    "NETDEV WATCHDOG: eno2d1 (bnxt_en_bpo): transmit queue 0 timed out"
    See attached kern.log excerpt file for full excerpt of error log.

  * Release = Xenial
    Kernel = 4.4.0-141-generic #167
    eno2d1 = Product Name: Broadcom Adv. Dual 25Gb Ethernet

  * This caused the driver to reset in order to recover:

    "bnxt_en_bpo :19:00.1 eno2d1: TX timeout detected, starting
  reset task!"

    driver: bnxt_en_bpo
    version: 1.8.1
    source: ubuntu/bnxt/bnxt.c: bnxt_tx_timeout()

  * The loss of connectivity and softirq stall caused other failures
    on the system.

  * The bnxt_en_po driver is the imported Broadcom driver
    pulled in to support newer Broadcom HW (specific boards)
    while the bnx_en module continues to support the older
    HW. The current Linux upstream driver does not compile
    easily with the 4.4 kernel (too many changes).

  * This upstream and bnxt_en driver fix is a likely solution:
     "bnxt_en: Fix TX timeout during netpoll"
     commit: 73f21c653f930f438d53eed29b5e4c65c8a0f906

    This fix has not been applied to the bnxt_en_po driver
    version, but review of the code indicates that it is
    susceptible to the bug, and the fix would be reasonable.

  [Test Case]

  * Unfortunately, this is not easy to reproduce. Also, it is only seen
  on 4.4 kernels with newer Broadcom NICs supported by the bnxt_en_bpo
  driver.

  [Regression Potential]

  * The patch is restricted to the bpo driver, with very constrained
  scope - just the newest Broadcom NICs being used by the Xenial 4.4
  kernel (as opposed to the hwe 4.15 etc. kernels, which would have the
  in-tree fixed driver).

  * The patch is very small and backport is fairly minimal and simple.

  * The fix has been running on the in-tree driver in upstream mainline
  as well as the Ubuntu Linux in-tree driver, although the Broadcom
  driver has a lot of lower level code that is different, this piece is
  still the same.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1795659] Re: kernel panic using CIFS share in smb2_push_mandatory_locks()

2020-07-14 Thread Guilherme G. Piccoli
** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1795659

Title:
  kernel panic using CIFS share in smb2_push_mandatory_locks()

Status in linux package in Ubuntu:
  Fix Released
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux-azure source package in Bionic:
  Invalid
Status in linux source package in Cosmic:
  Won't Fix
Status in linux-azure source package in Cosmic:
  Invalid
Status in linux source package in Disco:
  Fix Released
Status in linux-azure source package in Disco:
  Invalid

Bug description:
  NOTICE: The new patch merge is being worked on
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856949 - if you
  face this issue, please report there!

  
  [Impact]

  * We got reports of a kernel crash in cifs module with the following
  signature:

  BUG: unable to handle kernel NULL pointer dereference at 0038
  IP: smb2_push_mandatory_locks+0x10e/0x3b0 [cifs]
  PGD 0 P4D 0
  RIP: 0010:smb2_push_mandatory_locks+0x10e/0x3b0 [cifs]
  Call Trace:
   cifs_oplock_break+0x12f/0x3d0 [cifs]
   process_one_work+0x14d/0x410
   worker_thread+0x4b/0x460
   kthread+0x105/0x140
  [...]

  * Low-level analysis (decodecode script output and the objdump of the
  function) revealed that we are crashing in a NULL ptr dereference when
  trying to access "cfile->tlink"; below, a snippet of the objdump at
  function smb2_push_mandatory_locks():

  [...]
  mov0x10(%r14),%r15   # %r15 = cifsFileInfo *cfile
  mov0x18(%r14),%rbx   # %rbx = cifsLockInfo *li = (fdlocks->locks)
  lea0x18(%r14),%r12
  mov0x90(%r15),%rax   # %rax = struct tcon_link *tlink (cfile->tlink)
  cmp%r12,%rbx
  mov0x38(%rax),%rax   # <--- TRAP [trying to get cifs_tcon *tl_tcon]
  [...]

  * After discussing the issue with CIFS maintainers (Steve French and
  Pavel Shilovsky) they suggested commit b98749cac4a6 ("CIFS: keep
  FileInfo handle live during oplock break")
  [http://git.kernel.org/linus/b98749cac4a6] as a fix for multiple
  reports of this kind of crash.

  * The fix was sent to stable kernels and is present in Ubuntu kernels
  5.0 and newer. We are requesting the SRU for this patch here in order
  to fix the crashes, after reports of successful testing with the patch
  (see below section) and since the patch is restricted to the cifs
  module scope and accepted on linux stable.

  * Alternatively the issue is known to be avoided when oplocks are
  disabled using "cifs.enable_oplocks=N" module parameter.

  [Test case]

  * Unfortunately we cannot reproduce the issue. The patch proposed here was
  validated by us with xfstests (instructions followed from
  https://wiki.samba.org/index.php/Xfstesting-cifs) and fio. Also, we
  have a user report of test validation using LISA 
(https://github.com/LIS/LISAv2).

  * Using xfstest with the exclusions proposed in the link above we
  managed to get the same results as a non-patched kernel, i.e., the
  same tests failed in both kernels, we didn't get worse results with
  the patch. Fio also didn't show noticeable performance regression with
  the patch.

  [Regression potential]

  * The patch was validated by the cifs filesystem maintainers (in fact
  they suggested its inclusion in Ubuntu) and by the aforementioned
  tests; also, the scope is restricted to cifs only so the likelihood of
  regressions is considered low.

  * Due to the nature of the code modification (add a new reference of a
  file handler and manipulate it in different places), I consider that
  if we have a regression it'll manifest as deadlock/blocked tasks, not
  something more serious like crashes or data corruption.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1880959] Re: Rules from the policy directory files are not reapplied after changes to the primary policy file

2020-07-14 Thread Corey Bryant
New package versions have been uploaded to the rocky-staging PPA and to
the bionic unapproved queue.

** Changed in: cloud-archive/mitaka
   Status: Triaged => Won't Fix

** Changed in: python-oslo.policy (Ubuntu Xenial)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1880959

Title:
  Rules from the policy directory files are not reapplied after changes
  to the primary policy file

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Won't Fix
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  In Progress
Status in Ubuntu Cloud Archive stein series:
  Fix Committed
Status in Ubuntu Cloud Archive train series:
  Fix Committed
Status in Ubuntu Cloud Archive ussuri series:
  Fix Committed
Status in oslo.policy:
  Fix Released
Status in python-oslo.policy package in Ubuntu:
  Fix Released
Status in python-oslo.policy source package in Xenial:
  Won't Fix
Status in python-oslo.policy source package in Bionic:
  Triaged
Status in python-oslo.policy source package in Eoan:
  Won't Fix
Status in python-oslo.policy source package in Focal:
  Fix Committed
Status in python-oslo.policy source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Based on the investigation here 
https://bugs.launchpad.net/charm-keystone/+bug/1880847 it was determined that 
rules from policy files located in the directory specified in the policy_dirs 
option (/etc//policy.d by default) are not re-applied after the 
rules from the primary policy file is re-applied due to a change.

  This leads to scenarios where incorrect rule combinations are active.

  Example from the test case in 1880847:

  * policy.json gets read with the following rule;
  "identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
  * rule.yaml from policy.d is read with the following rule;
  {'identity:list_credentials': '!'}
  * policy.json's mtime gets updated (with or without a content change) and 
overrides the rule to be
  "identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
  * rule.yaml doesn't get reapplied since it hasn't changed.

  [Test Case]
  == ubuntu ==

  The patches include unit tests that ensure the code is behaving as
  expected and has not regressed. These tests are run during every
  package build.

  == upstream ==
  For a particular version of oslo.policy:

  * put the attached test (https://bugs.launchpad.net/ubuntu/+source
  /python-
  oslo.policy/+bug/1880959/+attachment/5377753/+files/test_1880959.py)
  under oslo_policy/tests/test_1880959.py;

  * run tox -e cover -- oslo_policy.tests.test_1880959.EnforcerTest;
  * observe the failure;
  # ...
  testtools.matchers._impl.MismatchError: 'role:fakeA' != 'rule:admin'
  Ran 1 tests in 0.005s (+0.001s)
  FAILED (id=1, failures=1)

  * apply the patch;
  * run tox -e cover -- oslo_policy.tests.test_1880959.EnforcerTest
  * observe that the failure is no longer there.

  [Regression Potential]
  The regression potential is low given that there is test coverage in the 
olso.policy unit tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1880959/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1887043] Re: xenial/linux-oracle: 4.15.0-1050.54~16.04.1 -proposed tracker

2020-07-14 Thread Kleber Sacilotto de Souza
** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
-   https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
+   https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  -- swm properties --
  kernel-stable-master-bug: 1887044
  packages:
-   main: linux-oracle
-   meta: linux-meta-oracle
-   signed: linux-signed-oracle
+   main: linux-oracle
+   meta: linux-meta-oracle
+   signed: linux-signed-oracle
  phase: Packaging
  phase-changed: Friday, 10. July 2020 16:10 UTC
  reason:
-   build-packages-ppa: Pending -- building in ppa main:missing
- signed:missing
-   prepare-package: Stalled -- tag not published and package not
- uploaded
-   prepare-package-signed: Stalled -- tag not published and package not
- uploaded
+   build-packages-ppa: Pending -- building in ppa main:missing
+ signed:missing
+   prepare-package: Stalled -- tag not published and package not
+ uploaded
+   prepare-package-signed: Stalled -- tag not published and package not
+ uploaded
  replaces: bug 1885809
  variant: debs
- versions:
-   meta: 4.15.0.1049.40

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1887043

Title:
  xenial/linux-oracle: 4.15.0-1050.54~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  In Progress
Status in Kernel SRU Workflow prepare-package-meta series:
  In Progress
Status in Kernel SRU Workflow prepare-package-signed series:
  In Progress
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-oracle source package in Xenial:
  New

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
    https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  -- swm properties --
  kernel-stable-master-bug: 1887044
  packages:
main: linux-oracle
meta: linux-meta-oracle
signed: linux-signed-oracle
  phase: Packaging
  phase-changed: Friday, 10. July 2020 16:10 UTC
  reason:
prepare-package: Pending -- tag not published and package not
  uploaded
prepare-package-meta: Pending -- tag not published and package not
  uploaded
prepare-package-signed: Pending -- tag not published and package not
  uploaded
  replaces: bug 1885809
  variant: debs

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1887043/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp