[Kernel-packages] [Bug 1788432] Re: 4.15 s390x kernel BUG at /build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

2019-04-24 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788432

Title:
  4.15 s390x kernel BUG at /build/linux-
  Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  [SRU Justification]

  == Impact ==
  Several helper functions in the s390x code which handle accessing sysfs 
attributes were missing protection against races. Concurrent access would be 
able to trigger kernel bugs.

  == Fix ==
  The following two upstream commits (from v5.0 upstream) will fix the issue:

  78b1a52e05c9 virtio/s390: fix race in ccw_io_helper()
  2448a299ec41 virtio/s390: avoid race on vcdev->config

  == Testcase ==
  see below

  == Risk of Regression ==
  Changes are isolated to architecture code and are verified by running the 
stress testing, so overall should be low.


  uname -a
  Linux ckingvm1 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 
s390x s390x s390x GNU/Linux

  and same for 4.15.0-29-generic and 4.17.0-8-generic

  Steps to reproduce this bug:

  git clone git://kernel.ubuntu.com/cking/stress-ng
  cd stress-ng
  make clean
  make

  And run with:

  ./stress-ng --sysfs 0 -t 60

  .. wait a few seconds and then:

  [  119.445891] [ cut here ]
  [  119.445898] kernel BUG at 
/build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!
  [  119.446093] illegal operation: 0001 ilc:1 [#3] SMP
  [  119.446100] Modules linked in: binfmt_misc zfs(PO) zunicode(PO) zavl(PO) 
icp(PO) isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic vfio_ccw sha512_s390 sha256_s390 vfio_mdev sha1_s390 sha_common 
mdev vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl 
lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 
raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 linear virtio_net crc32_vx_s390 virtio_blk
  [  119.446166] CPU: 1 PID: 5420 Comm: stress-ng-sysfs Tainted: P  DO  
   4.15.0-33-generic #36-Ubuntu
  [  119.446168] Hardware name: IBM 2964 N63 400 (KVM/Linux)
  [  119.446170] Krnl PSW : 12d313d3 405835bc 
(virtblk_cache_type_show+0x82/0x88 [virtio_blk])
  [  119.446177]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 
RI:0 EA:3
  [  119.446194] Krnl GPRS: de6dc5c2779af7d7 7ffaba20 0040 
6545
  [  119.446196]03ff800058da 6546 6bf537c0 
6b60a100
  [  119.446198] 00690648 7cc3de40 
7a74b000
  [  119.446202]03ff80008210  03ff800058da 
7ac1bce8
  [  119.446210] Krnl Code: 03ff80005912: ebbff0a80004  lmg 
%r11,%r15,168(%r15)
  [  119.446210]03ff80005918: c0f40560  brcl
15,3ff800063d8
  [  119.446210]   #03ff8000591e: a7f40001  brc 
15,3ff80005920
  [  119.446210]   >03ff80005922: 0707  bcr 0,%r7
  [  119.446210]03ff80005924: 0707  bcr 0,%r7
  [  119.446210]03ff80005926: 0707  bcr 0,%r7
  [  119.446210]03ff80005928: c004  brcl
0,3ff80005928
  [  119.446210]03ff8000592e: eb6ff0480024  stmg
%r6,%r15,72(%r15)
  [  119.446226] Call Trace:
  [  119.446229] ([<03ff800058da>] virtblk_cache_type_show+0x3a/0x88 
[virtio_blk])
  [  119.446234]  [<00690684>] dev_attr_show+0x3c/0x80
  [  119.446240]  [<00424ab4>] sysfs_kf_seq_show+0xbc/0x1a8
  [  119.446259]  [<003b048c>] seq_read+0xec/0x4c8
  [  119.446262]  [<003821ea>] vfs_read+0x8a/0x150
  [  119.446274]  [<00382786>] SyS_read+0x66/0xe0
  [  119.446278]  [<008e3028>] system_call+0xdc/0x2c8
  [  119.446279] Last Breaking-Event-Address:
  [  119.446281]  [<03ff8000591e>] virtblk_cache_type_show+0x7e/0x88 
[virtio_blk]
  [  119.446283]
  [  119.446284] ---[ end trace 2c2403d726047e4a ]---

  For  4.17.0-8-generic:
  [   25.170715] kernel BUG at drivers/block/virtio_blk.c:574!
  [   25.170795] illegal operation: 0001 ilc:1 [#1] SMP
  [   25.170797] Modules linked in: lttng_statedump(OE) lttng_clock(OE) 
lttng_lib_ring_buffer(OE) binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) 
isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic sha512_s390 sha256_s390 sha1_s390 sha_common vfio_ccw vfio_mdev 
mdev vfio_iommu_type1 vfio 

[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-04-24 Thread Frank Heimes
** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-04-24 Thread Frank Heimes
Changed disco entry to Fix Released according to comment #3.

** Changed in: linux (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1776631] Re: [19.04 FEAT] I/O device pre-configuration

2019-04-23 Thread Frank Heimes
Closed (set to Fix Released), since this ticket covers the kernel part, which 
is done.
The installer bits and pieces are tracked in LP 1799684.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1776631

Title:
  [19.04 FEAT] I/O device pre-configuration

Status in subiquity:
  Invalid
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in debian-installer package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released

Bug description:
  I/O device auto-configuration is a mechanism by which users can specify IDs 
and settings of I/O devices that should be automatically enabled in Linux. 
Users enter this information for an LPAR via an HMC running in DPM mode. During 
boot, Linux obtains this information via an SCLP call (details to be defined) 
and triggers the resulting configuration actions (e.g. using the chzdev 
command).
  Available with kernel 4.17

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1776631] Re: [19.04 FEAT] I/O device pre-configuration

2019-04-23 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Incomplete => In Progress

** Changed in: debian-installer (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1776631

Title:
  [19.04 FEAT] I/O device pre-configuration

Status in subiquity:
  Incomplete
Status in Ubuntu on IBM z Systems:
  In Progress
Status in debian-installer package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released

Bug description:
  I/O device auto-configuration is a mechanism by which users can specify IDs 
and settings of I/O devices that should be automatically enabled in Linux. 
Users enter this information for an LPAR via an HMC running in DPM mode. During 
boot, Linux obtains this information via an SCLP call (details to be defined) 
and triggers the resulting configuration actions (e.g. using the chzdev 
command).
  Available with kernel 4.17

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1790835] Re: Ubuntu18.10 - crypto/vmx: Fix sleep-in-atomic bugs

2019-04-22 Thread Frank Heimes
*** This bug is a duplicate of bug 1790832 ***
https://bugs.launchpad.net/bugs/1790832

As you can see from top of this Launchpad ticket (page):
"This bug report is a duplicate of:  Bug #1790832: crypto/vmx - Backport of Fix 
sleep-in-atomic bugs patch for 18.04."
this ticket was marked as a duplicate of LP 1790832:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790832
and with that this ticket LP 1790835 is no longer updated, but LP 1790832 is.
And LP 1790832 is in state "Fixed Released" for Xenial, Bionic and Cosmic - 
hence this fix is included in virtually all available Ubuntu releases that are 
in (base) service (incl. Disco).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1790835

Title:
  Ubuntu18.10 - crypto/vmx: Fix sleep-in-atomic bugs

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New
Status in linux source package in Bionic:
  New

Bug description:
  == Comment: #0 - Paulo Flabiano Smorigo  - 2018-09-04 
15:07:23 ==
  Please include the following commit in order to fix the sleep-in-atomic bugs 
in AES-CBC and AES-XTS VMX implementations [1]:

  0522236 crypto: vmx - Fix sleep-in-atomic bugs

  [1]
  
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=0522236d4f9c5ab2e79889cb020d1acbe5da416e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1790835/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814899] Re: [19.04 FEAT] qeth: Performance Improvements

2019-04-16 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814899

Title:
  [19.04 FEAT] qeth: Performance Improvements

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Function:
  Improved performance for OSA and Hipersockets via general code improvements 
and and exploitation of further kernel infrastructure.

  Business Case:
  Improved network performance for Linux on Z

  Available with kernel 4.19:
  Git-Commit: 
s390/qeth: various buffer management cleanups [3b346c1814]
s390/qeth: remove unused buffer->aob pointer [f67a43a73b]
s390/qeth: fine-tune RX modesetting [9aa17df3b8]
s390/qeth: clean up Output Queue selection [86c0cdb9e0]
s390/qeth: consolidate ccwgroup driver definition [6d8769abe4]
s390/qeth: clean up exported symbols [09960b3a0a]
s390/qeth: increase GSO max size for eligible L3 devices [371a1e7a07]
s390/qeth: add a L3 xmit wrapper [ea1d4a0c7f]
s390/qeth: speed-up L3 IQD xmit [a647a02512]
s390/qeth: speed-up IPv4 OSA xmit [fb321f25e5]
s390/qeth: fix race in used-buffer accounting [a702349a40]
s390/qeth: reset layer2 attribute on layer switch [70551dc46f]
s390/qeth: remove redundant netif_carrier_ok() checks [addc5ee872]
s390/qeth: allocate netdevice early [d3d1b205e8]
s390/qeth: don't cache HW port number [92d2720969]
s390/qeth: simplify max MTU handling [8ce7a9e064]
s390/qeth: use core MTU range checking [72f219da79]
s390/qeth: add statistics for consumed buffer elements [d2a274b25b]
s390/qeth: merge linearize-check into HW header construction 
[ba86ceee9d]
s390/qeth: add support for constrained HW headers [a7c2f4a332]
s390/qeth: speed up L2 IQD xmit [5f89eca577]
s390/qeth: extract helper for MPC protocol type [73657a3e5b]
s390/qeth: reduce hard-coded access to ccw channels [750b162598]
s390/qeth: use qeth_setup_ccw() to set up all CCWs [45ca2fd646]
s390/qeth: do basic setup for data channel [24142fd8d8]
s390/qeth: clean up card initialization [95f4d8b75a]
s390/qeth: don't restrict qeth_card to DMA memory [f15cdaf237]
s390/qeth: switch on SG by default for IQD devices [04db741d0d]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814899/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1811354] Re: [19.04 FEAT] in-kernel crypto: support protected keys generated by random in paes module

2019-04-16 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811354

Title:
  [19.04 FEAT] in-kernel crypto: support protected keys generated by
  random in paes module

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released

Bug description:
  Allow the protected key AES (paes) module to derive protected keys from clear 
keys.
  This allows simple use of protected keys w/o requiring CryptoExpress adapters 
in case the keys are ephemeral, that their life time does not extend over 
different boot or machine migrations.
  An example of such keys are keys used to encrypt swap volumes of 
non-migratable systems.

  Function will be provided via kernel 4.20 .

  Important:
  Install file s390-pkey.conf introduced with this commit into 
/usr/lib/modules-load.d/ (or /etc/modules-load.d)

  
  Addl. Information for integration.

  Kernel module pkey is loaded too late during system startup.
   
  Kernel module pkey uses the CPU feature match mechanism to get loaded 
automatically when the CPU supports crypto. However, it gets loaded too late by 
the feature match mechanism. 

  When using the support added with "in-kernel crypto: support protected
  keys generated by random in paes module" to encrypt a swap disk with a
  randomly generated protected key, the pkey module must have been
  loaded before the /etc/crypttab is processed. It turned out that the
  automatic loading via CPU feature match is too late for that, and pkey
  is not yet loaded at the required point in time.

  The kernel module pkey should therefor loaded explicitly via
  /usr/lib/modules.load.d/.(or /etc/modules-load.d/). This is performed
  early enough, i.e. before /etc/crypttab is processed.

  Please integrate upstream commit
  
https://github.com/ibm-s390-tools/s390-tools/commit/dffd41943e5c01be2f343da7726edabf9d2ec05e
  titled "pkey: Support autoloading kernel pkey module". -> comes with
  kernel 4.20.

  Important:
  Install file s390-pkey.conf introduced with this commit into 
/usr/lib/modules-load.d/ (or /etc/modules-load.d)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1811354/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805793] Re: [19.04 FEAT] qeth: Full-blown TCP Segmentation Offload

2019-04-16 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805793

Title:
  [19.04 FEAT] qeth: Full-blown TCP Segmentation Offload

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  As of now, qeth only supports TCP Segmentation Offload (TSO) for IPv4 in 
Layer3 devices. 
  This feature extends the existing support to IPv6, and adds support for TSO 
in both IP variants for Layer2.

  Improved performance via improved TCP Segmentation offload also
  extended to IPv6 and for layer 2 devices

  kernel 4.20:
  Git-Commit: will follow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805793/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1799472] Re: [19.04 FEAT] Enable graphical distro installer to run natively with virtio-gpu

2019-04-16 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1799472

Title:
  [19.04 FEAT] Enable graphical distro installer to run natively with
  virtio-gpu

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Installer update request for completing
  [19.04 FEAT| Enable virtio-gpu for s390x 
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1799467

  Addl description:
  The graphical installers either require VNC to be set up on s390x to run or 
are not supported at all. 

  With virtio-gpu support the installers can start an X Windows server
  locally as they would on an x86 system.

  The distributor most likely only needs to disable s390x specific
  handling in the installer (like starting a VNC server) and just launch
  the graphical UI used for installation if a virtio-gpu device is
  present.

  Business Value: Allows to install s390x KVM guests without any extra
  setup activities, providing the same user experience as on other
  platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1799472/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1741904] Re: [18.04 FEAT] dm-crypt with protected keys - s390 tools part

2019-04-16 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1741904

Title:
  [18.04 FEAT] dm-crypt with protected keys - s390 tools part

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Extend dm-crypt to use protected keys to encrypt partitions.

  This feature has a 
  - kernel part,
  - part in the "crypt setup tool" as part of multipath tools
  - part in s390-tools for the zkey 

  This is the part for s390-tools part > 2.1.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1741904/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part

2019-04-16 Thread Frank Heimes
Hi Kleber, the cosmic and bionic systems that I updated with the
kernel(s) from proposed are running now for more than 11 days without
any issues, hence I would call that verified successful - if it's okay
and sufficient for you, too.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814892

Title:
  [19.04 FEAT] qeth: Enhanced link speed - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  SRU Justification:
  --

  * This is more a request (rather than a bug) to add support for the newest 
OSA-Express7S (network-) card,
so that even cosmic and bionic users should be able to benefit from it.

  * The support became upstream accepted with 4.20, mainly with commit

  [Test Case]

  * Due to the absence of that particular card in our (Canonical)
  system, the testing is up to IBM.

  * The recognition of the card type itself can be done via 'lsqeth |
  grep card_type',

  * and the functionality can be tested by network test tools, like
  stress-ng.

  * A regression test can of course be done on our (Canonical) system.

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there only the qeth driver/module.

  * The patch itself is less complex and adds mainly lines and fields
  for the recognition of the new card.

  * The entire code needed is already included in disco and a sniff test was 
done based on disco's kernel 5.0.
  __

  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks

  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814892/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1819989] Re: Add basic support to NVLink2 passthrough

2019-04-12 Thread Frank Heimes
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1819989

Title:
  Add basic support to NVLink2 passthrough

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  This bug exists to track the basic support to NVLink2 passthrough on
  Ubuntu 18.04 - for the guest side only. There's a relative small
  patchset that I'm going to send to Canonical Kernel Team using this
  buglink.

  On the host side we'll be running a custom version of Ubuntu 18.04
  (kernel + qemu). However on the guest side it will be *very important*
  for clients to simply download the Ubuntu 18.04 from Canonical's
  website and have the NVLink2 working out of the box.

  For that, we have worked on a small patchset using only upstream
  patches without changing beyond our area.

  As soon as I send the patchset to the mailing list I'll update this
  bug with a link to that message.

  Thank you very much,

  Jose R. Ziviani

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1819989/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command

2019-04-11 Thread Frank Heimes
** Changed in: linux (Ubuntu)
   Status: New => Invalid

** Changed in: ubuntu-z-systems
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1820275

Title:
  btrfs-kernel oops from btrfs subvolume delete command

Status in Ubuntu on IBM z Systems:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  This report show a kernel oops in the btrfs lugin , happened every few
  days when running a test suite on a test system. It looks like their
  systemd/Journal failed to kick off a dump immediately following the
  panic.

  The exploiter is using the kernel 4.15.0-42

  We're not sure it's the btrfs subvolume delete that's causing it yet

  Following infos are attached: - syslog - sosreport - kdump output here
  : https://ibm.ent.box.com/folder/70219521934

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1820275/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process

2019-04-10 Thread Frank Heimes
FW part is tracked in LP 1824117

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1646805

Title:
  MAC address needs to be unique and unchanged during entire netboot
  process

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Currently the MAC address is not solely used to id the machine or system.
  It is at the moment used to id the interface that the MAC represents.
  (At a very early state in the process the MAC address is missing or only 
available from inside the partition.)

  The minimum PXE boot requirements need to be satisfied in general.
  The boot loader is part of the firmware and not loaded from the server.
  So that means the firmware needs to provide the MAC address.
  But the MAC address is not available at that time, so it's not available 
upfront.

  MaaS is using the same MAC address for the initial DHCP request as for the 
network boot.
  Hence an initially known MAC address is required that needs to be static and 
doesn't change (on subsequent boots for that instance).

  There might be an IBM internal ticket already open for this - please
  check.

  Furthermore the firmware needs to requests files like this:
  pxelinux.cfg/01-88-99-aa-bb-cc-dd
  pxelinux.cfg/default
  And BOOTIF support is required:
  See 'petitboot doesn't handle ipappend in pxelinux.cfg'
  https://bugs.launchpad.net/tasty-taco/+bug/1322307
  for reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1824101] Re: [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr

2019-04-10 Thread Frank Heimes
I just looked up these two commits in the disco master tree and found that both 
commits are already tagged with 4.19 - hence they are in disco's latest kernel 
5.0:
$ git show bf399c2cadfa66d399d01d5a92a7bb0a112f1568 | head -n 6
commit bf399c2cadfa66d399d01d5a92a7bb0a112f1568
Author: Parav Pandit 
Date:   Tue Jun 5 08:40:17 2018 +0300

IB/core: Introduce GID attribute get, put and hold APIs

$ git describe --tags --contains bf399c2cadfa66d399d01d5a92a7bb0a112f1568
v4.19~309^2~312
$ git show b4c296f9c96420b8e7e92466ea5960f10ee20aae | head -n 6
commit b4c296f9c96420b8e7e92466ea5960f10ee20aae
Author: Jason Gunthorpe 
Date:   Fri Aug 17 16:45:51 2018 -0600

RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr

$ git describe --tags --contains b4c296f9c96420b8e7e92466ea5960f10ee20aae
v4.19~309^2~2
fheimes@T570:~/ubuntu-disco/disco$
Hence closing the ticket as Fix Released.

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

** Changed in: ubuntu-z-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824101

Title:
  [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  If commit bf399c2cadfa66d399d01d5a92a7bb0a112f1568 (RDMA) is applied, 
  the corresponding SMC patch also have to be applied.

  
  Problem Description:
  RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr 

  Symptom: 
  An SMC-R connection cannot be established. The GID value transferred in the 
confirm_link message is empty (i.e. binary zero).

  Problem:
  A change in the RDMA subsystem requires to update the way  to retrieve the 
GID of an RDMA device.

  Upstream-ID:   b4c296f9c96420b8e7e92466ea5960f10ee20aae
  Component  :  kernel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1824101/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1824101] Re: [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr

2019-04-10 Thread Frank Heimes
** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824101

Title:
  [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr

Status in Ubuntu on IBM z Systems:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  If commit bf399c2cadfa66d399d01d5a92a7bb0a112f1568 (RDMA) is applied, 
  the corresponding SMC patch also have to be applied.

  
  Problem Description:
  RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr 

  Symptom: 
  An SMC-R connection cannot be established. The GID value transferred in the 
confirm_link message is empty (i.e. binary zero).

  Problem:
  A change in the RDMA subsystem requires to update the way  to retrieve the 
GID of an RDMA device.

  Upstream-ID:   b4c296f9c96420b8e7e92466ea5960f10ee20aae
  Component  :  kernel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1824101/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1788098] Re: Avoid migration issues with aligned 2MB THB

2019-04-08 Thread Frank Heimes
Hi Leonardo,
unfortunately there was an issue with the SRU request and Juerg NACK-ed it, 
please have a look here:
https://lists.ubuntu.com/archives/kernel-team/2019-March/099128.html
Please re-submit the SRU request with the requested corrections.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788098

Title:
  Avoid migration issues with aligned 2MB THB

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete
Status in qemu package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Incomplete
Status in linux source package in Cosmic:
  Invalid

Bug description:
  FYI: This blocks bug 1781526 - once this one here is resolved we can
  go on with SRU considerations for 1781526

  --- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT---

  Hi, in some environments it was observed that this qemu patch to
  enable THP made it more likely to hit guest migration issues, however
  the following kernel patch resolves those migration issues:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=c066fafc595eef5ae3c83ae3a8305956b8c3ef15
  KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix()

  Once merged upstream, it would be good to include that change as well
  to avoid potential migration problems. Should I open a new bug for
  that or is it better to track here?

  Note Paelzer: I have not seen related migration issues myself, but it
  seems reasonable and confirmed by IBM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1788098/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command

2019-04-08 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1820275

Title:
  btrfs-kernel oops from btrfs subvolume delete command

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  New

Bug description:
  This report show a kernel oops in the btrfs lugin , happened every few
  days when running a test suite on a test system. It looks like their
  systemd/Journal failed to kick off a dump immediately following the
  panic.

  The exploiter is using the kernel 4.15.0-42

  We're not sure it's the btrfs subvolume delete that's causing it yet

  Following infos are attached: - syslog - sosreport - kdump output here
  : https://ibm.ent.box.com/folder/70219521934

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1820275/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part

2019-04-05 Thread Frank Heimes
I did a regression test and ran iperf3 (single thread and 4 threads in 
parallel) from cosmic to bionic (bionic target) and vice versa (cosmic target) 
a couple of times.
On top of that I'm of course also remotely connected to these system via OSA 
(since some hours) using the updated/expanded driver.
Everything looks good and is stable so far - I also did not noticed any 
performance degradation (by accident I ran some tests earlier this week and 
compared the throughput, and it's virtually the same).
All this done on z13 with OSA Express 5S.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814892

Title:
  [19.04 FEAT] qeth: Enhanced link speed - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  SRU Justification:
  --

  * This is more a request (rather than a bug) to add support for the newest 
OSA-Express7S (network-) card,
so that even cosmic and bionic users should be able to benefit from it.

  * The support became upstream accepted with 4.20, mainly with commit

  [Test Case]

  * Due to the absence of that particular card in our (Canonical)
  system, the testing is up to IBM.

  * The recognition of the card type itself can be done via 'lsqeth |
  grep card_type',

  * and the functionality can be tested by network test tools, like
  stress-ng.

  * A regression test can of course be done on our (Canonical) system.

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there only the qeth driver/module.

  * The patch itself is less complex and adds mainly lines and fields
  for the recognition of the new card.

  * The entire code needed is already included in disco and a sniff test was 
done based on disco's kernel 5.0.
  __

  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks

  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814892/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1788432] Re: 4.15 s390x kernel BUG at /build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

2019-04-05 Thread Frank Heimes
Successfully verified on cosmic:

ubuntu@hwe0002:~/stress-ng$ apt-cache policy linux-generic
linux-generic:
  Installed: 4.18.0.18.19
  Candidate: 4.18.0.18.19
  Version table:
 *** 4.18.0.18.19 500
500 http://us.ports.ubuntu.com/ubuntu-ports cosmic-proposed/main s390x 
Packages
100 /var/lib/dpkg/status
 4.18.0.17.18 500
500 http://us.ports.ubuntu.com/ubuntu-ports cosmic-updates/main s390x 
Packages
500 http://ports.ubuntu.com/ubuntu-ports cosmic-security/main s390x 
Packages
 4.18.0.10.11 500
500 http://us.ports.ubuntu.com/ubuntu-ports cosmic/main s390x Packages
ubuntu@hwe0002:~/stress-ng$ uname -r
4.18.0-18-generic
ubuntu@hwe0002:~/stress-ng$ ./stress-ng --sysfs 0 -t 60
stress-ng: info:  [11889] dispatching hogs: 4 sysfs
stress-ng: info:  [11889] successful run completed in 60.00s (1 min, 0.00 secs)
ubuntu@hwe0002:~/stress-ng$

and on bionic:
ubuntu@hwe0007:~/stress-ng$ apt-cache policy linux-generic
linux-generic:
  Installed: 4.15.0.48.50
  Candidate: 4.15.0.48.50
  Version table:
 *** 4.15.0.48.50 500
500 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x 
Packages
100 /var/lib/dpkg/status
 4.15.0.47.49 500
500 http://us.ports.ubuntu.com/ubuntu-ports bionic-updates/main s390x 
Packages
500 http://ports.ubuntu.com/ubuntu-ports bionic-security/main s390x 
Packages
 4.15.0.20.23 500
500 http://us.ports.ubuntu.com/ubuntu-ports bionic/main s390x Packages
ubuntu@hwe0007:~/stress-ng$ uname -r
4.15.0-48-generic
ubuntu@hwe0007:~/stress-ng$ ./stress-ng --sysfs 0 -t 60
stress-ng: info:  [9386] dispatching hogs: 4 sysfs
stress-ng: info:  [9386] successful run completed in 60.00s (1 min, 0.00 secs)
ubuntu@hwe0007:~/stress-ng$

Adjusting tags accordingly...

** Tags removed: verification-needed-bionic verification-needed-cosmic
** Tags added: verification-done verification-done-bionic 
verification-done-cosmic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788432

Title:
  4.15 s390x kernel BUG at /build/linux-
  Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  [SRU Justification]

  == Impact ==
  Several helper functions in the s390x code which handle accessing sysfs 
attributes were missing protection against races. Concurrent access would be 
able to trigger kernel bugs.

  == Fix ==
  The following two upstream commits (from v5.0 upstream) will fix the issue:

  78b1a52e05c9 virtio/s390: fix race in ccw_io_helper()
  2448a299ec41 virtio/s390: avoid race on vcdev->config

  == Testcase ==
  see below

  == Risk of Regression ==
  Changes are isolated to architecture code and are verified by running the 
stress testing, so overall should be low.


  uname -a
  Linux ckingvm1 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 
s390x s390x s390x GNU/Linux

  and same for 4.15.0-29-generic and 4.17.0-8-generic

  Steps to reproduce this bug:

  git clone git://kernel.ubuntu.com/cking/stress-ng
  cd stress-ng
  make clean
  make

  And run with:

  ./stress-ng --sysfs 0 -t 60

  .. wait a few seconds and then:

  [  119.445891] [ cut here ]
  [  119.445898] kernel BUG at 
/build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!
  [  119.446093] illegal operation: 0001 ilc:1 [#3] SMP
  [  119.446100] Modules linked in: binfmt_misc zfs(PO) zunicode(PO) zavl(PO) 
icp(PO) isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic vfio_ccw sha512_s390 sha256_s390 vfio_mdev sha1_s390 sha_common 
mdev vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl 
lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 
raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 linear virtio_net crc32_vx_s390 virtio_blk
  [  119.446166] CPU: 1 PID: 5420 Comm: stress-ng-sysfs Tainted: P  DO  
   4.15.0-33-generic #36-Ubuntu
  [  119.446168] Hardware name: IBM 2964 N63 400 (KVM/Linux)
  [  119.446170] Krnl PSW : 12d313d3 405835bc 
(virtblk_cache_type_show+0x82/0x88 [virtio_blk])
  [  119.446177]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 
RI:0 EA:3
  [  119.446194] Krnl GPRS: de6dc5c2779af7d7 7ffaba20 0040 
6545
  [  119.446196]03ff800058da 6546 6bf537c0 
6b60a100
  [  119.446198] 00690648 7cc3de40 
7a74b000
  [  119.446202]03ff80008210  

[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-04-05 Thread Frank Heimes
Thx again - entire verification is done - changing tags.

** Tags removed: verification-needed-cosmic
** Tags added: verification-done verification-done-cosmic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-04-05 Thread Frank Heimes
Thank you - adjusting tag.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process

2019-04-05 Thread Frank Heimes
Hi, well Firmware is a broad term - let me split it up into two cases:
1) boot  from CD or FTP server (e.g. 'Load from Removeable Media and 
Server' task),
   then install to disk and reboot from that disk - possible in classic HMC 
mode and DPM
2) boot  from network server (PXE-like), then install to disk and 
reboot from that disk
   afaik DPM mode only

Obviously both requires firmware support - but probably different
components.

The MAC address should not change (in the above examples) between the
1st boot (e.g. installer) and the 2nd (re-)boot (e.g. a post-install
restart of the system from disk).

Having MAAS in mind we particularly require the 2nd case (network-
booting an LPAR in DPM, installing to disk and restarting from that disk
and always having the same unique MAC address).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1646805

Title:
  MAC address needs to be unique and unchanged during entire netboot
  process

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Currently the MAC address is not solely used to id the machine or system.
  It is at the moment used to id the interface that the MAC represents.
  (At a very early state in the process the MAC address is missing or only 
available from inside the partition.)

  The minimum PXE boot requirements need to be satisfied in general.
  The boot loader is part of the firmware and not loaded from the server.
  So that means the firmware needs to provide the MAC address.
  But the MAC address is not available at that time, so it's not available 
upfront.

  MaaS is using the same MAC address for the initial DHCP request as for the 
network boot.
  Hence an initially known MAC address is required that needs to be static and 
doesn't change (on subsequent boots for that instance).

  There might be an IBM internal ticket already open for this - please
  check.

  Furthermore the firmware needs to requests files like this:
  pxelinux.cfg/01-88-99-aa-bb-cc-dd
  pxelinux.cfg/default
  And BOOTIF support is required:
  See 'petitboot doesn't handle ipappend in pxelinux.cfg'
  https://bugs.launchpad.net/tasty-taco/+bug/1322307
  for reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part

2019-04-05 Thread Frank Heimes
** Description changed:

+ SRU Justification:
+ --
+ 
+ * This is more a request (rather than a bug) to add support for the newest 
OSA-Express7S (network-) card,
+   so that even cosmic and bionic users should be able to benefit from it.
+ 
+ * The support became upstream accepted with 4.20, mainly with commit
+ 
+ [Test Case]
+ 
+ * Due to the absence of that particular card in our (Canonical) system,
+ the testing is up to IBM.
+ 
+ * The recognition of the card type itself can be done via 'lsqeth | grep
+ card_type',
+ 
+ * and the functionality can be tested by network test tools, like
+ stress-ng.
+ 
+ * A regression test can of course be done on our (Canonical) system.
+ 
+ [Regression Potential]
+ 
+ * The regression potential can be considered as low since it only
+ affects the s390x platform
+ 
+ * and there only the qeth driver/module.
+ 
+ * The patch itself is less complex and adds mainly lines and fields for
+ the recognition of the new card.
+ 
+ * The entire code needed is already included in disco and a sniff test was 
done based on disco's kernel 5.0.
+ __
+ 
  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks
  
  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814892

Title:
  [19.04 FEAT] qeth: Enhanced link speed - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  SRU Justification:
  --

  * This is more a request (rather than a bug) to add support for the newest 
OSA-Express7S (network-) card,
so that even cosmic and bionic users should be able to benefit from it.

  * The support became upstream accepted with 4.20, mainly with commit

  [Test Case]

  * Due to the absence of that particular card in our (Canonical)
  system, the testing is up to IBM.

  * The recognition of the card type itself can be done via 'lsqeth |
  grep card_type',

  * and the functionality can be tested by network test tools, like
  stress-ng.

  * A regression test can of course be done on our (Canonical) system.

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there only the qeth driver/module.

  * The patch itself is less complex and adds mainly lines and fields
  for the recognition of the new card.

  * The entire code needed is already included in disco and a sniff test was 
done based on disco's kernel 5.0.
  __

  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks

  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814892/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process

2019-04-04 Thread Frank Heimes
Hi Jochen, not sure if I got that right - so let me rephrase according
to our needs:

Does that mean - and can you conform - that this unique MAC address
patch for PXE boot applies to a z14 in DPM mode with a certain level
(tbd) of firmware code?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1646805

Title:
  MAC address needs to be unique and unchanged during entire netboot
  process

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Currently the MAC address is not solely used to id the machine or system.
  It is at the moment used to id the interface that the MAC represents.
  (At a very early state in the process the MAC address is missing or only 
available from inside the partition.)

  The minimum PXE boot requirements need to be satisfied in general.
  The boot loader is part of the firmware and not loaded from the server.
  So that means the firmware needs to provide the MAC address.
  But the MAC address is not available at that time, so it's not available 
upfront.

  MaaS is using the same MAC address for the initial DHCP request as for the 
network boot.
  Hence an initially known MAC address is required that needs to be static and 
doesn't change (on subsequent boots for that instance).

  There might be an IBM internal ticket already open for this - please
  check.

  Furthermore the firmware needs to requests files like this:
  pxelinux.cfg/01-88-99-aa-bb-cc-dd
  pxelinux.cfg/default
  And BOOTIF support is required:
  See 'petitboot doesn't handle ipappend in pxelinux.cfg'
  https://bugs.launchpad.net/tasty-taco/+bug/1322307
  for reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1741860] Re: Use the kernel default for crashkernel offset

2019-04-04 Thread Frank Heimes
Hi Mamatha, well, as you can see from Launchpad comment #6:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1741860/comments/6
we are still waiting for the feedback from IBM about the validation mentioned 
in comment #5:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1741860/comments/5

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1741860

Title:
  Use the kernel default for crashkernel offset

Status in The Ubuntu-power-systems project:
  Incomplete
Status in makedumpfile package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Hari Krishna Bathini  - 2018-01-08 
01:06:41 ==
  ---Problem Description---
  A default offset of 128MB is enforced for crashkernel by kdump-tools utility
  overriding the kernel default.

  While the kernel default offset for crashkernel is also 128MB, that may change
  and the right thing to do would be to let the kernel decide on the offset of
  crashkernel in the default scenario.. 

  Get rid of "@128M" in kdump-tools.cfg file

   
  Contact Information = hbath...@in.ibm.com 
   
  ---uname output---
  na
   
  Machine Type = na 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   # cat /etc/default/grub.d/kdump-tools.cfg 
  GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M@128M"
  ---

  The offset is specified via kdump-tools where as the kernel may be the right 
place to
  set an offset by default..

   
  Userspace tool common name: kdump-tools 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: kdump-tools

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for hbath...@in.ibm.com:
  -Attach ltrace and strace of userspace application.

  == Comment: #3 - MAMATHA INAMDAR  - 2018-01-08 03:05:05 
==
  This bug is opened to follow-up other bug based on the comment 19
  https://bugzilla.linux.ibm.com/show_bug.cgi?id=152905#c19 (Canonical 
Launchpad1676884 )

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1741860/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process

2019-04-03 Thread Frank Heimes
@ltraeger, the patch above, that's part of disco, only works in combination 
with a z14 (and again a pretty recent firmware level). It doesn't change the 
situation on z13 or z13s.
So z14 (or z14 ZR1) is a prerequisite.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1646805

Title:
  MAC address needs to be unique and unchanged during entire netboot
  process

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Currently the MAC address is not solely used to id the machine or system.
  It is at the moment used to id the interface that the MAC represents.
  (At a very early state in the process the MAC address is missing or only 
available from inside the partition.)

  The minimum PXE boot requirements need to be satisfied in general.
  The boot loader is part of the firmware and not loaded from the server.
  So that means the firmware needs to provide the MAC address.
  But the MAC address is not available at that time, so it's not available 
upfront.

  MaaS is using the same MAC address for the initial DHCP request as for the 
network boot.
  Hence an initially known MAC address is required that needs to be static and 
doesn't change (on subsequent boots for that instance).

  There might be an IBM internal ticket already open for this - please
  check.

  Furthermore the firmware needs to requests files like this:
  pxelinux.cfg/01-88-99-aa-bb-cc-dd
  pxelinux.cfg/default
  And BOOTIF support is required:
  See 'petitboot doesn't handle ipappend in pxelinux.cfg'
  https://bugs.launchpad.net/tasty-taco/+bug/1322307
  for reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1822870] Re: Backport support for software count cache flush Spectre v2 mitigation. (CVE) (required for POWER9 DD2.3)

2019-04-02 Thread Frank Heimes
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => Critical

** Information type changed from Public to Public Security

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Kernel Security Team 
(canonical-kernel-security-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1822870

Title:
  Backport support for software count cache flush Spectre v2 mitigation.
  (CVE) (required for POWER9 DD2.3)

Status in The Ubuntu-power-systems project:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  For the different kernels:

  The HWE a563fd9c62f0 UBUNTU: Ubuntu-hwe-4.18.0-17.18~18.04.1 appears
  to have all patches.

  Disco appears to be missing only this patch:
  92edf8df0ff2ae86cc632eeca0e651fd8431d40d powerpc/security: Fix spectre_v2 
reporting

  Cosmic (which is supported until July) is missing a number of patches:
  cf175dc315f90185128fb061dc05b6fbb211aa2f powerpc/64: Disable the speculation 
barrier from the command line
  6453b532f2c8856a80381e6b9a1f5ea2f12294df powerpc/64: Make stf barrier 
PPC_BOOK3S_64 specific.
  179ab1cbf883575c3a585bcfc0f2160f1d22a149 powerpc/64: Add 
CONFIG_PPC_BARRIER_NOSPEC
  af375eefbfb27cbb5b831984e66d724a40d26b5c powerpc/64: Call 
setup_barrier_nospec() from setup_arch()
  406d2b6ae3420f5bb2b3db6986dc6f0b6dbb637b powerpc/64: Make meltdown reporting 
Book3S 64 specific
  06d0bbc6d0f56dacac3a79900e9a9a0d5972d818 powerpc/asm: Add a patch_site macro 
& helpers for patching instructions
  dc8c6cce9a26a51fc19961accb978217a3ba8c75 powerpc/64s: Add new security 
feature flags for count cache flush
  ee13cb249fabdff8b90aaff61add347749280087 powerpc/64s: Add support for 
software count cache flush
  ba72dc171954b782a79d25e0f4b3ed91090c3b1e powerpc/pseries: Query hypervisor 
for count cache flush settings
  99d54754d3d5f896a8f616b0b6520662bc99d66b powerpc/powernv: Query firmware for 
count cache flush settings
  7d8bad99ba5a22892f0cad6881289fdc3875a930 powerpc/fsl: Fix spectre_v2 
mitigations reporting
  92edf8df0ff2ae86cc632eeca0e651fd8431d40d powerpc/security: Fix spectre_v2 
reporting
  This appears to already be in -next.

  For the bionic 18.04.1 (4.15) kernel only this patch is already part of 
master-next:
  a6b3964ad71a61bb7c61d80a60bea7d42187b2eb powerpc/64s: Add barrier_nospec

  The others are ported, there were only 3 that were not clean.  Those are:
  2eea7f067f495e33b8b116b35b5988ab2b8aec55 powerpc/64s: Add support for ori 
barrier_nospec patching
  This failed because commit a048a07d7f4535baa4cbad6bc024f175317ab938 is 
missing, but it does not look like that is required here.

  cb3d6759a93c6d0aea1c10deb6d00e111c29c19c powerpc/64s: Enable barrier_nospec 
based on firmware settings
  This failed because debugfs was already included, I can see that previously 
added, I didn't see where it was previously removed.

  06d0bbc6d0f56dacac3a79900e9a9a0d5972d818 powerpc/asm: Add a patch_site macro 
& helpers for patching instructions
  This failed because 8183d99f4a22c is not included - but doesn't seem 
necessary.

  All other patches applied with, at most, some fuzz.

  Has had a little testing - boots, check debugfs, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1822870/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1804149] Re: Kernel panic, Oops: 0004 ilc:3 [#1] SMP, iscsi_q_20 iscsi_xmitworker [libiscsi]

2019-04-02 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1804149

Title:
  Kernel panic,Oops: 0004 ilc:3 [#1] SMP,  iscsi_q_20 iscsi_xmitworker
  [libiscsi]

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Triaged

Bug description:
  == Comment: #0 - Michael Finnegan  - 2018-11-19 14:14:40 
==
  ---Problem Description---
  Kernel panic,Oops: 0004 ilc:3 [#1] SMP,  iscsi_q_20 iscsi_xmitworker 
[libiscsi]
   
  ---uname output---
  Linux ilabg3 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:13:24 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM 3906 M05 7G4 (z/VM 7.1.0) 
   
  ---Debugger---
  A debugger is not configured
   
  Contact Information = Michael Finnegan/finne...@us.ibm.com 
   
  Stack trace output:
   dmesg.201811161956
  [1363037.322472] Unable to handle kernel pointer dereference in virtual 
kernel address space
  [1363037.322481] Failing address:  TEID: 0483
  [1363037.322483] Fault in home space mode while using kernel ASCE.
  [1363037.322486] AS:00ea0007 R3:f37d0007 S:f37ff000 
P:013d
  [1363037.322524] Oops: 0004 ilc:3 [#1] SMP
  [1363037.322529] Modules linked in: iptable_filter binfmt_misc 
rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache qeth_l3 qeth_l2 
s390_trng ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 
sha1_s390 sha_common qeth vmur ccwgroup vfio_ccw vfio_mdev mdev 
vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core sunrpc 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables 
dm_round_robin dm_service_time crc32_vx_s390 dasd_eckd_mod zfcp qdio 
scsi_transport_fc dasd_fba_mod dasd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua 
dm_multipath
  [1363037.322567] CPU: 3 PID: 37970 Comm: kworker/u128:19 Not tainted 
4.15.0-36-generic #39-Ubuntu
  [1363037.322573] Hardware name: IBM 3906 M05 7G4 (z/VM 7.1.0)
  [1363037.322581] Workqueue: iscsi_q_20 iscsi_xmitworker [libiscsi]
  [1363037.322583] Krnl PSW : c8051cf6 e49a28f4 
(__iscsi_get_task+0x6/0x18 [libiscsi])
  [1363037.322587]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 
PM:0 RI:0 EA:3
  [1363037.322589] Krnl GPRS:  02923ce0 
 0400
  [1363037.322591]03ff80277640 0008 
788efc00 03ff802777cc
  [1363037.322592]03ff8027769c  
 78ce8310
  [1363037.322594]f3689800 78ce83a2 
03ff80272e8e 02923c90
  [1363037.322601] Krnl Code: 03ff80272624: c0f4fcf6  brcl
15,3ff80272010
  03ff8027262a: c0f4377b  brcl
15,3ff80279520
 #03ff80272630: c004  brcl
0,3ff80272630
 >03ff80272636: eb012078006a  asi 
120(%r2),1
  03ff8027263c: c0f43772  brcl
15,3ff80279520
  03ff80272642: 0707  bcr 0,%r7
  03ff80272644: 0707  bcr 0,%r7
  03ff80272646: 0707  bcr 0,%r7
  [1363037.322618] Call Trace:
  [1363037.322621] ([<03ff80272ec6>] iscsi_xmit_task+0x86/0x138 [libiscsi])
  [1363037.322625]  [<03ff8027769c>] iscsi_data_xmit+0x44c/0x548 [libiscsi]
  [1363037.322636]  [<03ff802777cc>] iscsi_xmitworker+0x34/0x58 [libiscsi]
  [1363037.322642]  [<001918f2>] process_one_work+0x262/0x4d8
  [1363037.322644]  [<00191bc0>] worker_thread+0x58/0x4e8
  [1363037.322648]  [<00198d24>] kthread+0x14c/0x168
  [1363037.322652]  [<008e3eb2>] kernel_thread_starter+0xa/0x10
  [1363037.322654]  [<008e3ea8>] kernel_thread_starter+0x0/0x10
  [1363037.322655] Last Breaking-Event-Address:
  [1363037.322657]  [<03ff80272e88>] iscsi_xmit_task+0x48/0x138 [libiscsi]
  [1363037.322658]
  [1363037.322660] Kernel panic - not syncing: Fatal exception in interrupt

  
   
  Oops output:
Oops: 0004 ilc:3 [#1] SMP


  *Additional Instructions for Michael Finnegan/finne...@us.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on. 
  -Attach sysctl -a output output to the bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1804149/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1719545] Re: [P9][LTCTest][Opal][FW910] cpupower monitor shows multiple stop Idle_Stats

2019-04-01 Thread Frank Heimes
** Changed in: ubuntu-power-systems
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1719545

Title:
  [P9][LTCTest][Opal][FW910] cpupower monitor shows multiple stop
  Idle_Stats

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  == Comment: #0 - PAVAMAN SUBRAMANIYAM  - 2017-06-29 
02:30:22 ==
  ---Problem Description---
  cpupower monitor shows multiple stop Idle_Stats
   

   
  ---uname output---
  Linux zz376p1 4.10.0-26-generic #30~16.04.1-Ubuntu SMP Tue Jun 27 09:38:48 
UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = P9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  Install a P9 8375-42A Hardware with Ubuntu 16.04.3 OS.
  Then execute the cpupower monitor command to fetch all the Idle_Stats values.

  root@zz376p1:~# cpupower monitor
|Idle_Stats
  PKG |CORE|CPU | snoo | stop | stop
 0|   8|   0|  0.00|  0.00|  2.79
 0|   8|   1|  0.00|  0.00| 70.68
 0|   8|   2|  0.00|  0.00| 99.87
 0|   8|   3|  0.00|  0.00| 67.28
 0|  12|   4|  0.00|  0.00|  5.17
 0|  12|   5|  0.00|  0.00| 12.50
 0|  12|   6|  0.00|  0.00| 99.74
 0|  12|   7|  0.00|  0.00|  0.00
 8|2048|   8|  0.00|  0.00| 22.14
 8|2048|   9|  0.00|  0.00| 102.3
 8|2048|  10|  0.00|  0.00|  0.00
 8|2048|  11|  0.00|  0.00| 99.97
 8|2052|  12|  0.00|  0.00| 99.70
 8|2052|  13|  0.00|  0.00| 23.86
 8|2052|  14|  0.00|  0.00| 113.1
 8|2052|  15|  0.00|  0.00|  0.00

  As can be seen it shows 2 columns for stop.

  root@zz376p1:~# uname -a
  Linux zz376p1 4.10.0-26-generic #30~16.04.1-Ubuntu SMP Tue Jun 27 09:38:48 
UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  root@zz376p1:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="16.04.2 LTS (Xenial Xerus)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 16.04.2 LTS"
  VERSION_ID="16.04"
  HOME_URL="http://www.ubuntu.com/;
  SUPPORT_URL="http://help.ubuntu.com/;
  BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;
  VERSION_CODENAME=xenial
  UBUNTU_CODENAME=xenial

  root@zz376p1:~# cat /proc/cpuinfo | tail
  processor   : 15
  cpu : POWER9 (raw), altivec supported
  clock   : 2600.00MHz
  revision: 1.0 (pvr 004e 0100)

  timebase: 51200
  platform: PowerNV
  model   : 8375-42A
  machine : PowerNV 8375-42A
  firmware: OPAL
   
  Userspace tool common name: /usr/bin/cpupower 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: linux-tools-common

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for pavsu...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.

  
  .
  There are 3 idle_stats (3 states) in this system. 

  root@zz376p1:/sys/devices/system/cpu/cpu0/cpuidle/state2# cpupower monitor -l
  Monitor "Idle_Stats" (3 states) - Might overflow after 4294967295 s
  snoo  [T] -> snooze
  stop  [T] -> stop0_lite
  stop  [T] -> stop1_lite

  root@zz376p1:/sys/devices/system/cpu/cpu0/cpuidle/state2# cpupower idle-info
  CPUidle driver: powernv_idle
  CPUidle governor: menu
  analyzing CPU 0:

  Number of idle states: 3
  Available idle states: snooze stop0_lite stop1_lite
  snooze:
  Flags/Description: snooze
  Latency: 0
  Usage: 224
  Duration: 423
  stop0_lite:
  Flags/Description: stop0_lite
  Latency: 0
  Usage: 1685
  Duration: 530522
  stop1_lite:
  Flags/Description: stop1_lite
  Latency: 4
  Usage: 12693
  Duration: 5405898106

  root@zz376p1:/sys/devices/system/cpu/cpu0/cpuidle/state2# cpupower monitor -l
  Monitor "Idle_Stats" (3 states) - Might overflow after 4294967295 s
  snoo  [T] -> snooze
  stop  [T] -> stop0_lite
  stop  [T] -> stop1_lite
  root@zz376p1:/sys/devices/system/cpu/cpu0/cpuidle/state2# cpupower idle-info
  CPUidle driver: powernv_idle
  CPUidle governor: menu
  analyzing CPU 0:

  Number of idle states: 3
  Available idle states: snooze stop0_lite stop1_lite
  snooze:
  Flags/Description: snooze
  Latency: 0
  Usage: 272
  Duration: 905
  stop0_lite:
  Flags/Description: stop0_lite
  Latency: 0
  Usage: 2141
  Duration: 536399
  stop1_lite:
  Flags/Description: stop1_lite
  Latency: 4
  Usage: 15396
  Duration: 6625668881

  
  cpu monitor will print the results of all the 3 available idle_stats .

  The first stop -> stop0_lite stats
  and
  The second stop -> stop1_lite stats.

  cpupower monitor header prints the header list by getting the name of
  the idle stats.

  name  (name description)
  snoo   [T] -> snooze
  stop   [T] -> stop0_lite
  stop   [T] -> stop1_lite

  We can change the header to be more 

[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part

2019-03-29 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814892

Title:
  [19.04 FEAT] qeth: Enhanced link speed - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks

  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814892/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818645] Re: Ubuntu18.04.01: [Power9] power8 Compat guest(RHEL7.6) crashes during guest boot with > 256G of memory (kernel/kvm)

2019-03-29 Thread Frank Heimes
Since the fix is already included in the disco kernel I'm changing the root 
'linux (Ubuntu)' entry (that is usually used to track the current development 
release kernel) to Fix Released.
And because the bionic entry is Fix Committed I adjust the project entry and 
change it to Fix Committed, too.

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

** Changed in: ubuntu-power-systems
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818645

Title:
  Ubuntu18.04.01: [Power9] power8 Compat guest(RHEL7.6) crashes during
  guest boot with > 256G of memory (kernel/kvm)

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  == SRU Justification ==

  Rebooting a PowerPC VM with > 256G of memory results in a guest crash.

  == Fix ==

  Backport commit 46dec40fb741 ("KVM: PPC: Book3S HV: Don't truncate
  HPTE index in xlate function").

  == Regression Potential ==

  Low. Fix is trivial.

  == Test Case ==

  Create a PowerPC VM with > 256G of memory and reboot it repeatedly.

  == Original description ==

  == Comment: #0 - Satheesh Rajendran  - 2019-02-28 
04:38:22 ==
  ---Problem Description---
  Power8 Compat guest(RHEL 7.6) crashes during guest boot with > 256G of memory 
(kernel/kvm)

  Contact Information = sathe...@in.ibm.com

  ---uname output---
  Host Kernel: 4.15.0-1016-ibm-gt

  ii  qemu-system-ppc1:2.11+dfsg-
  1ubuntu7.8-1ibm3   ppc64el  QEMU
  full system emulation binaries (ppc)

  ii  libvirt-bin4.0.0-1ubuntu8.6
  ppc64el  programs for the libvirt library

  Guest kernel: 3.10.0-957.5.1.el7.ppc64le (rhel7.6 zstream)

  Machine Type = power9 ppc64le

  ---Steps to Reproduce---
   1. Boot a power8 compat guest with memory >256G
  virsh define avocado-vt-vm1;virsh start --console avocado-vt-vm1 (guest xml 
sosreport attached)
  Guest crashes while booting

  2019-02-28 10:36:44.752+: starting up libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100), qemu version: 2.11.1(Debian 
1:2.11+dfsg-1ubuntu7.8-1ibm3), hostname: cs-host-f37-ac922-3.pok.ibm.com
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-ppc64 -name 
guest=avocado-vt-vm1,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-avocado-vt-vm1/master-key.aes
 -machine pseries-2.11,accel=kvm,usb=off,dump-guest-core=off -m 264192 
-realtime mlock=off -smp 256,sockets=256,cores=1,threads=1 -uuid 
f4e14f88-bf1b-4cc3-b6d6-958d514d6c18 -display none -no-user-config -nodefaults 
-chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-15-avocado-vt-vm1/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device 
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive 
file=/home/sath/avocado-fvt-wrapper/data/avocado-vt/images/rhel76-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:fd:fe,bus=pci.0,addr=0x1 
-chardev pty,id=charserial0 -device 
spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 -chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-15-avocado-vt-vm1/org.qemu.guest_agent.0,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
  2019-02-28 10:36:44.759+: 19598: info : libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100)
  2019-02-28 10:36:44.759+: 19598: info : hostname: cs-host-f37-ac922-3
  2019-02-28 10:36:44.759+: 19598: info : virObjectUnref:350 : 
OBJECT_UNREF: obj=0x76d594111710
  2019-02-28T10:36:44.781703Z qemu-system-ppc64: -chardev pty,id=charserial0: 
char device redirected to /dev/pts/3 (label charserial0)
  2019-02-28T10:36:44.781945Z qemu-system-ppc64: warning: Number of SMP cpus 
requested (256) exceeds the recommended cpus supported by KVM (128)
  2019-02-28T10:36:44.781953Z qemu-system-ppc64: warning: Number of 
hotpluggable cpus requested (256) exceeds the recommended cpus supported by KVM 
(128)
  2019-02-28 10:37:18.060+: shutting down, reason=crashed
  2019-02-28T10:37:18.071969Z qemu-system-ppc64: terminating 

[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-03-29 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1766201] Re: CTAUTO:DevOps:860.50:devops4fp1:Error occurred during LINUX Dmesg error Checking for all LINUX clients for devops4p10

2019-03-28 Thread Frank Heimes
** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

** Changed in: ubuntu-power-systems
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1766201

Title:
  CTAUTO:DevOps:860.50:devops4fp1:Error occurred during LINUX Dmesg
  error Checking for all LINUX clients for devops4p10

Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Application Cdeadmin  -
  2018-04-20 05:56:03 ==

  
  == Comment: #1 - Application Cdeadmin  - 2018-04-20 
05:56:05 ==
   State: Open by: stccdenv on 18 April 2018 06:27:28 

  This defect was opened automatically using defect_template with only
  logs. Please refer to 2nd seq for the problem description.

  ==Automatic entries==
  Full Log: 
http://w3.austin.ibm.com/afs/awd.austin.ibm.com/u/stccdenv/logs/devops4fp1_defect_template_20180418060138

  Contact: Thirukumaran V T (thirukuma...@in.ibm.com), Tommy 
Adams(tnad...@us.ibm.com)
  Backup: Atit Patel (a...@us.ibm.com)

  System Name: devops4fp1
  FSP IP: 9.3.136.192 (devops4fp1.aus.stglabs.ibm.com)
  System Firmware Level:
   Current Side Driver:.fips861/b0413a_1816.861
   Non-Current Side Driver:.fips861/b0410a_1816.861

  Lpar Access: Please refer https://pcajet.aus.stglabs.ibm.com/ for the lab 
password. (The Lab Test Passwords are now accessible only through the auto or 
manual install web apps. For example, from the manual install web app, enter 
your email address, check the Lab Passwords checkbox and then click on Submit.)
  (To access the Lpars in 10.33.x.x network, login to any LCB or HMC then 
ssh/telnet to 10.33.x.x lpars)

  ---
  HMC IP: 9.3.118.110 (vhmccloudtst100.aus.stglabs.ibm.com)
  HMC Version:
  "version= Version: 9
   Release: 1
   Service Pack: 910
  HMC Build level 1803052221
  ","base_version=V9R1
  "

  ---

  =Logs
  SNAP : 
  devops4p02: /tmp/ibmsupt/snap.pax.Z.devops4p02.180418060149 and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/snap.pax.Z.devops4p02.180418060149  
/tmp/IBM.DRM.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060149.tar.gz.devops4p02  
/tmp/htx.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/htx.180418060149.tar.gz.devops4p02  
  devops4p03: /tmp/ibmsupt/snap.pax.Z.devops4p03.180418060149 and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/snap.pax.Z.devops4p03.180418060149  
/tmp/IBM.DRM.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060149.tar.gz.devops4p03  
/tmp/htx.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/htx.180418060149.tar.gz.devops4p03  
  devops4p04: /tmp/ibmsupt/snap.pax.Z.devops4p04.180418060148 and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/snap.pax.Z.devops4p04.180418060148  
/tmp/IBM.DRM.180418060148.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060148.tar.gz.devops4p04  
/tmp/htx.180418060148.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/htx.180418060148.tar.gz.devops4p04  
  devops4p05: /tmp/ibmsupt/snap.pax.Z.devops4p05.180418060148 and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/snap.pax.Z.devops4p05.180418060148  
/tmp/IBM.DRM.180418060148.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060148.tar.gz.devops4p05  
/tmp/htx.180418060148.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/htx.180418060148.tar.gz.devops4p05  
  devops4p06: /tmp/ctsupt/ctsnap.linux-hjmh.04180701.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/ctsnap.linux-hjmh.04180701.tar.gz  
/tmp/var_log.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/var_log.180418060149.tar.gz  
/var/log/nts_linux-hjmh_180418_0703.tbz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/nts_linux-hjmh_180418_0703.tbz  
/tmp/IBM.DRM.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060149.tar.gz.devops4p06  
/tmp/htx.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/htx.180418060149.tar.gz.devops4p06  
  devops4p07: /tmp/ctsupt/ctsnap.devops4p07.04180601.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/ctsnap.devops4p07.04180601.tar.gz  
/tmp/var_log.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/var_log.180418060149.tar.gz  
/var/tmp/sosreport-devops4p07.aus.stglabs.ibm.com-20180418060350.tar.xz and 
also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/sosreport-devops4p07.aus.stglabs.ibm.com-20180418060350.tar.xz
  /tmp/IBM.DRM.180418060149.tar.gz and also @ 
(NFS)9.41.164.242:/fspmount/hmc_dumps/IBM.DRM.180418060149.tar.gz.devops4p07  

[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-03-27 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  New
Status in linux source package in Cosmic:
  New
Status in linux source package in Disco:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1788098] Re: Avoid migration issues with aligned 2MB THB

2019-03-26 Thread Frank Heimes
** Changed in: linux (Ubuntu Bionic)
   Status: Confirmed => In Progress

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788098

Title:
  Avoid migration issues with aligned 2MB THB

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  In Progress
Status in qemu package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Cosmic:
  Invalid

Bug description:
  FYI: This blocks bug 1781526 - once this one here is resolved we can
  go on with SRU considerations for 1781526

  --- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT---

  Hi, in some environments it was observed that this qemu patch to
  enable THP made it more likely to hit guest migration issues, however
  the following kernel patch resolves those migration issues:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=c066fafc595eef5ae3c83ae3a8305956b8c3ef15
  KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix()

  Once merged upstream, it would be good to include that change as well
  to avoid potential migration problems. Should I open a new bug for
  that or is it better to track here?

  Note Paelzer: I have not seen related migration issues myself, but it
  seems reasonable and confirmed by IBM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1788098/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-03-25 Thread Frank Heimes
Kernel SRU request submitted: 
https://lists.ubuntu.com/archives/kernel-team/2019-March/099478.html
https://lists.ubuntu.com/archives/kernel-team/2019-March/thread.html#99478

** Description changed:

+ SRU Justification:
+ 
+ [Impact]
+ 
+ * The vfio-ap driver will create a matrix device in sysfs without a
+ subsystem link.
+ 
+ * This causes failures in libudev that might also lead to libvirt
+ errors.
+ 
+ * A fix is upstream in master branch for kernel 5.1
+ 
+ [Fix]
+ 
+ * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap: link
+ the vfio_ap devices to the vfio_ap bus subsystem"
+ 
+ [Test Case]
+ 
+ * An s390x machine with at least one CryptoExpress card,
+   where at least one AP and one 'Domain' is assigned to a particular LPAR.
+ 
+ * Now running virsh nodedev-list before (and later after) construction
+ the matrix device should expose the issue.
+ 
+ * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
+   (see 2nd bullet: virtio-ap)
+ 
+ [Regression Potential]
+ 
+ * The regression potential can be considered as low since it only
+ affects the s390x platform
+ 
+ * and there it only affects the usage of AP (CryptoExpress) cards and
+ it's driver/module
+ 
+ * and again only affects the recently introduced virtual IO function of
+ AP (vfio-ap).
+ 
+ [Other Info]
+ 
+ * It was already briefly discussed here:
+   https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
+   as well as reviewed and pushed.
+ 
+ * Commit 3636065 from v5.1-rc1
+ 
+ * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!
+ 
+ * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
+ _
+ 
  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)
  
  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).
  
- 
  A fix for that is upstream in master branch already for kernel 5.1
  
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99
  
  This  need to be applied to Bionic, Cosmic and Disco

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  SRU Justification:

  [Impact]

  * The vfio-ap driver will create a matrix device in sysfs without a
  subsystem link.

  * This causes failures in libudev that might also lead to libvirt
  errors.

  * A fix is upstream in master branch for kernel 5.1

  [Fix]

  * 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 3636065 "s390: vfio_ap:
  link the vfio_ap devices to the vfio_ap bus subsystem"

  [Test Case]

  * An s390x machine with at least one CryptoExpress card,
where at least one AP and one 'Domain' is assigned to a particular LPAR.

  * Now running virsh nodedev-list before (and later after) construction
  the matrix device should expose the issue.

  * For details about how to setup a vfio-ap matrix device see: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
(see 2nd bullet: virtio-ap)

  [Regression Potential]

  * The regression potential can be considered as low since it only
  affects the s390x platform

  * and there it only affects the usage of AP (CryptoExpress) cards and
  it's driver/module

  * and again only affects the recently introduced virtual IO function
  of AP (vfio-ap).

  [Other Info]

  * It was already briefly discussed here:
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html
as well as reviewed and pushed.

  * Commit 3636065 from v5.1-rc1

  * This affects ccw cards and their vf only, NOT vf of PCI/PCIe cards!

  * For details on virtio-ap/vfio-ap see bullet #2 here: 
http://kvmonz.blogspot.com/2018/12/qemu-v31-released.html
  _

  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1788432] Re: 4.15 s390x kernel BUG at /build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

2019-03-25 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788432

Title:
  4.15 s390x kernel BUG at /build/linux-
  Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  [SRU Justification]

  == Impact ==
  Several helper functions in the s390x code which handle accessing sysfs 
attributes were missing protection against races. Concurrent access would be 
able to trigger kernel bugs.

  == Fix ==
  The following two upstream commits (from v5.0 upstream) will fix the issue:

  78b1a52e05c9 virtio/s390: fix race in ccw_io_helper()
  2448a299ec41 virtio/s390: avoid race on vcdev->config

  == Testcase ==
  see below

  == Risk of Regression ==
  Changes are isolated to architecture code and are verified by running the 
stress testing, so overall should be low.


  uname -a
  Linux ckingvm1 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 
s390x s390x s390x GNU/Linux

  and same for 4.15.0-29-generic and 4.17.0-8-generic

  Steps to reproduce this bug:

  git clone git://kernel.ubuntu.com/cking/stress-ng
  cd stress-ng
  make clean
  make

  And run with:

  ./stress-ng --sysfs 0 -t 60

  .. wait a few seconds and then:

  [  119.445891] [ cut here ]
  [  119.445898] kernel BUG at 
/build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!
  [  119.446093] illegal operation: 0001 ilc:1 [#3] SMP
  [  119.446100] Modules linked in: binfmt_misc zfs(PO) zunicode(PO) zavl(PO) 
icp(PO) isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic vfio_ccw sha512_s390 sha256_s390 vfio_mdev sha1_s390 sha_common 
mdev vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl 
lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 
raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 linear virtio_net crc32_vx_s390 virtio_blk
  [  119.446166] CPU: 1 PID: 5420 Comm: stress-ng-sysfs Tainted: P  DO  
   4.15.0-33-generic #36-Ubuntu
  [  119.446168] Hardware name: IBM 2964 N63 400 (KVM/Linux)
  [  119.446170] Krnl PSW : 12d313d3 405835bc 
(virtblk_cache_type_show+0x82/0x88 [virtio_blk])
  [  119.446177]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 
RI:0 EA:3
  [  119.446194] Krnl GPRS: de6dc5c2779af7d7 7ffaba20 0040 
6545
  [  119.446196]03ff800058da 6546 6bf537c0 
6b60a100
  [  119.446198] 00690648 7cc3de40 
7a74b000
  [  119.446202]03ff80008210  03ff800058da 
7ac1bce8
  [  119.446210] Krnl Code: 03ff80005912: ebbff0a80004  lmg 
%r11,%r15,168(%r15)
  [  119.446210]03ff80005918: c0f40560  brcl
15,3ff800063d8
  [  119.446210]   #03ff8000591e: a7f40001  brc 
15,3ff80005920
  [  119.446210]   >03ff80005922: 0707  bcr 0,%r7
  [  119.446210]03ff80005924: 0707  bcr 0,%r7
  [  119.446210]03ff80005926: 0707  bcr 0,%r7
  [  119.446210]03ff80005928: c004  brcl
0,3ff80005928
  [  119.446210]03ff8000592e: eb6ff0480024  stmg
%r6,%r15,72(%r15)
  [  119.446226] Call Trace:
  [  119.446229] ([<03ff800058da>] virtblk_cache_type_show+0x3a/0x88 
[virtio_blk])
  [  119.446234]  [<00690684>] dev_attr_show+0x3c/0x80
  [  119.446240]  [<00424ab4>] sysfs_kf_seq_show+0xbc/0x1a8
  [  119.446259]  [<003b048c>] seq_read+0xec/0x4c8
  [  119.446262]  [<003821ea>] vfs_read+0x8a/0x150
  [  119.446274]  [<00382786>] SyS_read+0x66/0xe0
  [  119.446278]  [<008e3028>] system_call+0xdc/0x2c8
  [  119.446279] Last Breaking-Event-Address:
  [  119.446281]  [<03ff8000591e>] virtblk_cache_type_show+0x7e/0x88 
[virtio_blk]
  [  119.446283]
  [  119.446284] ---[ end trace 2c2403d726047e4a ]---

  For  4.17.0-8-generic:
  [   25.170715] kernel BUG at drivers/block/virtio_blk.c:574!
  [   25.170795] illegal operation: 0001 ilc:1 [#1] SMP
  [   25.170797] Modules linked in: lttng_statedump(OE) lttng_clock(OE) 
lttng_lib_ring_buffer(OE) binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) 
isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic sha512_s390 sha256_s390 sha1_s390 sha_common vfio_ccw vfio_mdev 
mdev vfio_iommu_type1 vfio 

[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part

2019-03-22 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814892

Title:
  [19.04 FEAT] qeth: Enhanced link speed - kernel part

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  New
Status in linux source package in Cosmic:
  New

Bug description:
  Function:
  Provide enhanced link speed for OSA networks
  Business Case:
  Improved performance with OSA networks

  Available with kernel 4.20
  Git-Commit: s390/qeth: report 25Gbit link speed [54e049c227]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814892/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command

2019-03-18 Thread Frank Heimes
The kernel in use is 4.15.0-42, but current one (from '-updates' pocket) is 
4.15.0.46.48.
It's generally recommended to run on the latest released kernel level.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1820275

Title:
  btrfs-kernel oops from btrfs subvolume delete command

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  This report show a kernel oops in the btrfs lugin , happened every few
  days when running a test suite on a test system. It looks like their
  systemd/Journal failed to kick off a dump immediately following the
  panic.

  The exploiter is using the kernel 4.15.0-42

  We're not sure it's the btrfs subvolume delete that's causing it yet

  Following infos are attached: - syslog - sosreport - kdump output here
  : https://ibm.ent.box.com/folder/70219521934

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1820275/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command

2019-03-18 Thread Frank Heimes
For accessibility reasons I transferred the dump to 'mombin' - can be found in 
my home (fheimes):
S215B-CHAIN6-zaas-2019-03-01T16_22_36-AZIZ0104E-0aa776d0-ba53-43ed-8462-a2b1cc5ef46c.bin

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1820275

Title:
  btrfs-kernel oops from btrfs subvolume delete command

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  This report show a kernel oops in the btrfs lugin , happened every few
  days when running a test suite on a test system. It looks like their
  systemd/Journal failed to kick off a dump immediately following the
  panic.

  The exploiter is using the kernel 4.15.0-42

  We're not sure it's the btrfs subvolume delete that's causing it yet

  Following infos are attached: - syslog - sosreport - kdump output here
  : https://ibm.ent.box.com/folder/70219521934

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1820275/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command

2019-03-15 Thread Frank Heimes
** Description changed:

- Description will follow
+ This report show a kernel oops in the btrfs lugin , happened every few
+ days when running a test suite on a test system. It looks like their
+ systemd/Journal failed to kick off a dump immediately following the
+ panic.
+ 
+ The exploiter is using the kernel 4.15.0-42
+ 
+ We're not sure it's the btrfs subvolume delete that's causing it yet
+ 
+ Following infos are attached: - syslog - sosreport - kdump output here :
+ https://ibm.ent.box.com/folder/70219521934

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Status: New => Triaged

** Changed in: ubuntu-z-systems
   Importance: Undecided => Medium

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1820275

Title:
  btrfs-kernel oops from btrfs subvolume delete command

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  This report show a kernel oops in the btrfs lugin , happened every few
  days when running a test suite on a test system. It looks like their
  systemd/Journal failed to kick off a dump immediately following the
  panic.

  The exploiter is using the kernel 4.15.0-42

  We're not sure it's the btrfs subvolume delete that's causing it yet

  Following infos are attached: - syslog - sosreport - kdump output here
  : https://ibm.ent.box.com/folder/70219521934

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1820275/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1790778] Re: crypto/vmx - Backport of Fix sleep-in-atomic bugs patch for 16.04

2019-03-15 Thread Frank Heimes
*** This bug is a duplicate of bug 1790832 ***
https://bugs.launchpad.net/bugs/1790832

Since this bug got marked as duplicate of LP 1790832 in last September (what 
you btw, might not see in the Bugzilla system itself and w/o having a look at 
LP directly), there is no further activity on this one.
For the latest status please now have a look at LP 1790832 
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790832),
and that is already Fix Released, including xenial / 16.04.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1790778

Title:
  crypto/vmx - Backport of Fix sleep-in-atomic bugs patch for 16.04

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Paulo Flabiano Smorigo  - 2018-09-04 
15:02:20 ==
  Please include the following commit in order to fix the sleep-in-atomic bugs 
in AES-CBC and AES-XTS VMX implementations [1]:

  0522236 crypto: vmx - Fix sleep-in-atomic bugs

  [1]
  
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=0522236d4f9c5ab2e79889cb020d1acbe5da416e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1790778/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1817097] Re: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices

2019-03-13 Thread Frank Heimes
Decreasing importance from critical to medium, because the bug is known to the 
community, it is already discussed in RH Bug 1669751, and here 
https://www.redhat.com/archives/linux-lvm/2019-February/msg00018.html / 
https://www.redhat.com/archives/linux-lvm/2019-March/msg0.html, and not 
platform specific, nor specific to a certain Ubuntu release.
On top there are actions possible to easily avoid this situation, like 
explicitly setting / forcing the sector size to be 4096 bytes or using a bigger 
image size (>512 MB - which is not uncommon), so that the sector size default 
changes to 4k anyway.
A patch was already suggested upstream:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=dd6ff9e3a75801fc5c6166aa0983fa8df098e91a
Once that patch got upstream accepted and became picked-up in a new lvm2 
version, it will eventually land in Ubuntu, too.


** Changed in: ubuntu-z-systems
   Importance: Critical => Medium

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1817097

Title:
  pvmove causes file system corruption without notice upon move from 512
  -> 4096 logical block size devices

Status in lvm2:
  Confirmed
Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  Incomplete

Bug description:
  Problem Description---
  Summary
  ===
  Environment: IBM Z13 LPAR and z/VM Guest
   IBM Type: 2964 Model: 701 NC9
  OS:  Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x)
   Package: lvm2 version 2.02.176-4.1ubuntu3
  LVM: pvmove operation corrupts file system when using 4096 (4k) logical block 
size
   and default block size being 512 bytes in the underlying devices
  The problem is immediately reproducible.

  We see a real usability issue with data destruction as consequence - which is 
not acceptable.
  We expect 'pvmove' to fail with error in such situations to prevent fs 
destruction,
  which might possibly be overridden by a force flag.

  
  Details
  ===
  After a 'pvmove' operation is run to move a physical volume onto an ecrypted
  device with 4096 bytes logical block size we experience a file system 
corruption.
  There is no need for the file system to be mounted, but the problem surfaces
  differently if so.

  Either, the 'pvs' command after the pvmove shows
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument

  or

  a subsequent mount shows (after umount if the fs had previously been mounted 
as in our
  setup)
  mount: /mnt: wrong fs type, bad option, bad superblock on 
/dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error.

  A minimal setup of LVM using one volume group with one logical volume defined,
  based on one physical volume is sufficient to raise the problem. One more 
physical
  volume of the same size is needed to run the pvmove operation to. 

LV
 |
  VG: LOOP_VG [ ]
 |
  PV: /dev/loop0   -->   /dev/mapper/enc-loop
  ( backed by /dev/mapper/enc-loop )

  The physical volumes are backed by loopback devices (losetup) to base the
  problem report on, but we have seen the error on real SCSI multipath volumes
  also, with and without cryptsetup mapper devices in use.

  
  Further discussion
  ==
  https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html
  The problem does not occur on block devices with native size of 4k.
  E.g. DASDs, or file systems with mkfs -b 4096 option.

  
  Terminal output
  ===
  See attached file pvmove-error.txt

  
  Debug data
  ==
  pvmove was run with -dd (maximum debug level)
  See attached journal file.
   
  Contact Information = christian.r...@de.ibm.com 
   
  ---uname output---
  Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Type: 2964 Model: 701 NC9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1.) Create two image files of 500MB in size
  and set up two loopback devices with 'losetup -fP FILE'
  2.) Create one physical volume and one volume group 'LOOP_VG',
  and one logical volume 'VG'
  Run:
  pvcreate /dev/loop0
  vgcreate LOOP_VG /dev/loop0
  lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
  3.) Create a file system on the logical volume device:
  mkfs.ext4 /dev/mapper/LOOP_VG-LV
  4.) mount the file system created in the previous step to some empty 
available directory:
  mount /dev/mapper/LOOP_VG-LV /mnt
  5.) Set up a second physical volume, this time encrypted with LUKS2,
  and open the 

[Kernel-packages] [Bug 1804645] Re: [19.04 FEAT] kernel address sanitizer support

2019-03-11 Thread Frank Heimes
Since Kernel 5.0 just landed in disco's release pocket, I'm changing the
status to Fix Released.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1804645

Title:
  [19.04 FEAT] kernel address sanitizer support

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  KernelAddressSANitizer (KASAN) is a dynamic memory error detector.
  It provides a fast and comprehensive solution for finding use-after-free and 
out-of-bounds bugs.

  KASAN uses compile-time instrumentation for checking every memory access, 
therefore you will need a GCC version 4.9.2 or later.
  GCC 5.0 or later is required for detection of out-of-bounds accesses to stack 
or global variables.

  Implement the backend for Linux on Z to be able to use KASAN. Provide
  an additional RPM autobuild target for a KASAN enabled kernel.

  kernel 4.20
  Git-Commit : will follow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1804645/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805428] Re: [19.04 FEAT] Synthesize perf events/samples from CPU-MF auxtrace data

2019-03-11 Thread Frank Heimes
Since Kernel 5.0 just landed in disco's release pocket, I'm changing the
status to Fix Released.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805428

Title:
  [19.04 FEAT] Synthesize perf events/samples from CPU-MF auxtrace data

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Enable the Intel instruction trace (itrace), evaluate synthesizing perf 
events and samples from auxtrace buffe for s390x.
  The auxtrace buffer contains the CPU-MF sampling data blocks that contains 
basic- and diagnostic sampling data entries.  Similar to the cpum_sf PMU, parse 
the basic-sampling data entries and synthesize perf events/samples for each 
entry. This can be solely done in the perf tool.

  kernel 4.20:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805428/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814537] Re: [19.04 FEAT] Splitting DIF and DIX boot time controls

2019-03-11 Thread Frank Heimes
Since Kernel 5.0 just landed in disco's release pocket, I'm changing the
status to Fix Released.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814537

Title:
  [19.04 FEAT] Splitting DIF and DIX boot time controls

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Functions:
  A Linux on Z user can separately configure DIF and DIF+DIX integrity 
protection mechanisms.

  Business Value:
  Customers can improve data integrity protection for data stored on FCP 
storage by making use of hardware-based DIF data integrity checking between FCP 
channel and target LUN. Previously, this feature could only be enabled together 
with the DIX feature that has proven to be too unstable for production usage.

  Will be made available with kernel 5.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814537/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805429] Re: [19.04 FEAT] Extended access controls for AP queue - kernel part

2019-03-11 Thread Frank Heimes
Since Kernel 5.0 landed in disco's release pocket today, I'm changing
the status to Fix Released.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805429

Title:
  [19.04 FEAT] Extended access controls for AP queue - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Update description:
  Provide a means to control which user/process can access which APQN, or in 
other words enable to grant users/applications access to different (sets of) 
crypto adapters and domains.
  While keeping existing interfaces for compatibility, allow to use both DAC 
(e.g. Unix file permissions) and MAC (e.g. LSM) methods.

  Please enable the following kernel config option:
 *  CONFIG_ZCRYPT_MULTIDEVNODES=y

  
  will be made available with kernel 4.20

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805429/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process

2019-03-11 Thread Frank Heimes
Kernel 5.0 landed in disco's release pocket today, hence changing status
to Fix Released.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1646805

Title:
  MAC address needs to be unique and unchanged during entire netboot
  process

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Currently the MAC address is not solely used to id the machine or system.
  It is at the moment used to id the interface that the MAC represents.
  (At a very early state in the process the MAC address is missing or only 
available from inside the partition.)

  The minimum PXE boot requirements need to be satisfied in general.
  The boot loader is part of the firmware and not loaded from the server.
  So that means the firmware needs to provide the MAC address.
  But the MAC address is not available at that time, so it's not available 
upfront.

  MaaS is using the same MAC address for the initial DHCP request as for the 
network boot.
  Hence an initially known MAC address is required that needs to be static and 
doesn't change (on subsequent boots for that instance).

  There might be an IBM internal ticket already open for this - please
  check.

  Furthermore the firmware needs to requests files like this:
  pxelinux.cfg/01-88-99-aa-bb-cc-dd
  pxelinux.cfg/default
  And BOOTIF support is required:
  See 'petitboot doesn't handle ipappend in pxelinux.cfg'
  https://bugs.launchpad.net/tasty-taco/+bug/1322307
  for reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1811259] Re: 4.20 kernel on s390x VM crashes

2019-03-11 Thread Frank Heimes
Since Kernel 5.0 landed in disco's release pocket today, I'm changing
the status to Fix Released.

** Changed in: linux (Ubuntu Disco)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811259

Title:
  4.20 kernel on s390x VM crashes

Status in Linux:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  Booting with  4.20.0-2-generic on a s390x 2 CPU VM we hit a panic:

  [0.394835] Linux version 4.20.0-2-generic (buildd@bos02-s390x-015) (gcc 
version 8.2.0 (Ubuntu 8.2.0-13ubuntu1)) #3-Ubuntu SMP Thu Jan 3 18:43:01 UTC 
2019 (Ubuntu 4.20.0-2.3-generic 4.20.0)
  [0.394838] setup.289988: Linux is running under KVM in 64-bit mode
  [0.394846] setup.b050d0: The maximum memory size is 2048MB
  [0.394866] numa.196305: NUMA mode: plain
  [0.394893] cpu.33a262: 2 configured CPUs, 0 standby CPUs
  [0.394999] Write protected kernel read-only data: 10464k
  [0.395034] Zone ranges:
  [0.395035]   DMA  [mem 0x-0x7fff]
  [0.395037]   Normal   empty
  [0.395038] Movable zone start for each node
  [0.395039] Early memory node ranges
  [0.395041]   node   0: [mem 0x-0x7fff]
  [0.395042] Initmem setup node 0 [mem 
0x-0x7fff]
  [0.413802] percpu: Embedded 25 pages/cpu @(ptrval) s62208 r8192 
d32000 u102400
  [0.413824] Built 1 zonelists, mobility grouping on.  Total pages: 516096
  [0.413825] Policy zone: DMA
  [0.413827] Kernel command line: root=LABEL=cloudimg-rootfs
  [0.450276] Memory: 2034164K/2097152K available (8116K kernel code, 1079K 
rwdata, 2344K rodata, 992K init, 772K bss, 62988K reserved, 0K cma-reserved)
  [0.450283] random: get_random_u64 called from kmem_cache_open+0x4c/0x4f0 
with crng_init=0
  [0.450432] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=3, Nodes=1
  [0.450434] ftrace: allocating 27385 entries in 107 pages
  [0.473325] rcu: Hierarchical RCU implementation.
  [0.473327] rcu:   RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=3.
  [0.473328]Tasks RCU enabled.
  [0.473329] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
  [0.473330] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=3
  [0.475371] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
  [0.475402] clocksource: tod: mask: 0x max_cycles: 
0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
  [0.475558] printk: console [ttyS1] enabled
  [0.475623] pid_max: default: 32768 minimum: 301
  [0.475658] LSM: Security Framework initializing
  [0.475660] Yama: becoming mindful.
  [0.475677] AppArmor: AppArmor initialized
  [0.476134] Dentry cache hash table entries: 262144 (order: 9, 2097152 
bytes)
  [0.476352] Inode-cache hash table entries: 131072 (order: 8, 1048576 
bytes)
  [0.476370] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
  [0.476377] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 
bytes)
  [0.476726] rcu: Hierarchical SRCU implementation.
  [0.476927] smp: Bringing up secondary CPUs ...
  [0.477181] smp: Brought up 1 node, 2 CPUs
  [0.477549] devtmpfs: initialized
  [0.477882] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
  [0.477902] futex hash table entries: 1024 (order: 6, 262144 bytes)
  [0.478105] NET: Registered protocol family 16
  [0.478134] audit: initializing netlink subsys (disabled)
  [0.478183] audit: type=2000 audit(1547122707.960:1): state=initialized 
audit_enabled=0 res=1
  [0.478222] Spectre V2 mitigation: execute trampolines
  [0.479205] HugeTLB registered 1.00 MiB page size, pre-allocated 0 pages
  [0.479623] SCSI subsystem initialized
  [0.479856] NetLabel: Initializing
  [0.479858] NetLabel:  domain hash size = 128
  [0.479859] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
  [0.479871] NetLabel:  unlabeled traffic allowed by default
  [0.507362] VFS: Disk quotas dquot_6.6.0
  [0.507378] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
  [0.507486] AppArmor: AppArmor Filesystem Enabled
  [0.507847] NET: Registered protocol family 2
  [0.507976] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 
16384 bytes)
  [0.507994] TCP established hash table entries: 16384 (order: 5, 131072 
bytes)
  [0.508126] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
  [0.508235] TCP: Hash tables configured (established 16384 bind 16384)
  [0.508269] UDP hash 

[Kernel-packages] [Bug 1814684] Re: [19.04 FEAT] [LS1801] PCI Virtual function enablement

2019-03-11 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814684

Title:
  [19.04 FEAT] [LS1801] PCI Virtual function enablement

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Description:
  The common code Linux kernel PCI bus driver performs initialization steps of 
PCI virtual functions (SRIOV) in an order that is incompatible with Z firmware 
requirements. As a result, virtual functions cannot be used properly. This item 
is about ensuring that PCI virtual functions can be correctly enabled in Linux.

  Tentativ target ; kernel 5.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814684/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1819407] Re: Guest with vfio device pass-through crashes during reboot operation.

2019-03-11 Thread Frank Heimes
It 'looks like' Ubuntu 18.04 was used, but the kernel and package versions do 
not fit and/or are on a different level:
 Linux ltcgen3 4.15.0-1016-ibm-gt
 qemu-kvm 1:2.11+dfsg-1ubuntu7.9
 libvirt0:ppc64el 4.0.0-1ubuntu8.6
respectively:
 Kernel: 4.15.0-1016.18-fix1-ibm-gt
 qemu: 1:2.11+dfsg-1ubuntu7.8-1ibm3
 libvirt-bin : 4.0.0-1ubuntu8.6

Official levels on bionic are today:
 linux-generic | 4.15.0.46.48   | bionic-updates  | ppc64el
 qemu-kvm | 1:2.11+dfsg-1ubuntu7.10 | bionic-updates  | ppc64el
 libvirt-bin | 4.0.0-1ubuntu8.7 | bionic-updates  | ppc64el

Is in your environment only the above kernel patch required for fixing
this, or are also patches in qemu (and maybe even in libvirt) needed?
Since you are using at least an own and non-standard kernel and qemu
package.

I'm wondering why the versions in use are different from the ones in the Ubuntu 
archive ?
I think a retest with the latest standard Ubuntu packages needs to be done to 
ensure that the situation is the same (which I assume, but anyway).



** Changed in: ubuntu-power-systems
   Importance: Undecided => Critical

** Changed in: ubuntu-power-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1819407

Title:
  Guest with vfio device pass-through crashes during reboot operation.

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - SANTWANA SAMANTRAY  - 
2019-02-18 22:08:48 ==
  ---Problem Description---
  Guest with vfio device pass-through crashes during reboot operation.
  The below error is noticed in the libvirt.log of the guest.
  2019-02-18 09:43:55.348+: 19136: info : virObjectUnref:350 : 
OBJECT_UNREF: obj=0x71bdb80fae00
  2019-02-18T09:43:55.366229Z qemu-system-ppc64: -chardev pty,id=charserial0: 
char device redirected to /dev/pts/8 (label charserial0)
  2019-02-18T14:53:23.937306Z qemu-system-ppc64: Failed to create a window, ret 
= -1 (Cannot allocate memory)
  qemu: hardware error: vfio: DMA mapping failed, unable to continue
  CPU #0:
  NIP 0daf0010   LR bbc8 CTR cfa8 XER 
2004 CPU#0
  MSR 000102801000 HID0   HF 8000 iidx 3 didx 3
  TB   DECR 
  GPR00 800102803031 c018e4b1ae80 c16eba00 f000
  GPR04 01780ad0 0daf 000102801000 800102803033
  GPR08 0a00 80002933 0010 3030382030303038
  GPR12 8000 cfa8 0800 
  GPR16 2001 0010 c641e1a0 c018fd3dace0
  GPR20 c19a2ba0 c018fd05b098 c01852a8 0029
  GPR24 c018e4b1b154  0004 0001
  GPR28 0004 c018e4b1b154 c1780ab0 0004
  CR 4000  [ G  -  -  -  -  -  -  -  ] RES 
  FPR00 8d73d0cfdf8626c9   
  FPR04    
  FPR08   6c7967656e657261 
  FPR12 9265dacfc19031dd   
  FPR16    
  FPR20    
  FPR24    
  FPR28    
  FPSCR 
   SRR0 0daf0010  SRR1 000102801000PVR 004e1202 VRSAVE 

  SPRG0  SPRG1 cfa8  SPRG2 cfa8  SPRG3 

  SPRG4  SPRG5   SPRG6   SPRG7 

  HSRR0  HSRR1 
   CFAR 
   LPCR 03d4f41f
DAR 0c8be5f8b8b0  DSISR 0a00

  In this case, NVIDIA GPU was pass-through'ed to the guest. 
  0004:04:00.0 3D controller [0302]: NVIDIA Corporation GV100 [Tesla V100 SXM2] 
[10de:1db1] (rev a1)
  0004:05:00.0 3D controller [0302]: NVIDIA Corporation GV100 [Tesla V100 SXM2] 
[10de:1db1] (rev a1)

  The initial few attempts of the guest reboot is successful, however in
  subsequent trials of rebooting in a loop, the guest crashes.

  == Versions Installed ==
  qemu   1:2.11+dfsg-1ubuntu7.8-1ibm3
  qemu-kvm 1:2.11+dfsg-1ubuntu7.9
  qemu-system-ppc 1:2.11+dfsg-1ubuntu7.8-1ibm3
  libvirt0:ppc64el 4.0.0-1ubuntu8.6
   
  Contact Information = Santwana Samantray/santwana.samant...@in.ibm.com 
   
  ---uname output---
  Linux ltcgen3 4.15.0-1016-ibm-gt #18-Ubuntu SMP Thu Feb 7 16:58:31 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 

[Kernel-packages] [Bug 1819407] Re: Guest with vfio device pass-through crashes during reboot operation.

2019-03-11 Thread Frank Heimes
** Package changed: kernel-package (Ubuntu) => linux (Ubuntu)

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1819407

Title:
  Guest with vfio device pass-through crashes during reboot operation.

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - SANTWANA SAMANTRAY  - 
2019-02-18 22:08:48 ==
  ---Problem Description---
  Guest with vfio device pass-through crashes during reboot operation.
  The below error is noticed in the libvirt.log of the guest.
  2019-02-18 09:43:55.348+: 19136: info : virObjectUnref:350 : 
OBJECT_UNREF: obj=0x71bdb80fae00
  2019-02-18T09:43:55.366229Z qemu-system-ppc64: -chardev pty,id=charserial0: 
char device redirected to /dev/pts/8 (label charserial0)
  2019-02-18T14:53:23.937306Z qemu-system-ppc64: Failed to create a window, ret 
= -1 (Cannot allocate memory)
  qemu: hardware error: vfio: DMA mapping failed, unable to continue
  CPU #0:
  NIP 0daf0010   LR bbc8 CTR cfa8 XER 
2004 CPU#0
  MSR 000102801000 HID0   HF 8000 iidx 3 didx 3
  TB   DECR 
  GPR00 800102803031 c018e4b1ae80 c16eba00 f000
  GPR04 01780ad0 0daf 000102801000 800102803033
  GPR08 0a00 80002933 0010 3030382030303038
  GPR12 8000 cfa8 0800 
  GPR16 2001 0010 c641e1a0 c018fd3dace0
  GPR20 c19a2ba0 c018fd05b098 c01852a8 0029
  GPR24 c018e4b1b154  0004 0001
  GPR28 0004 c018e4b1b154 c1780ab0 0004
  CR 4000  [ G  -  -  -  -  -  -  -  ] RES 
  FPR00 8d73d0cfdf8626c9   
  FPR04    
  FPR08   6c7967656e657261 
  FPR12 9265dacfc19031dd   
  FPR16    
  FPR20    
  FPR24    
  FPR28    
  FPSCR 
   SRR0 0daf0010  SRR1 000102801000PVR 004e1202 VRSAVE 

  SPRG0  SPRG1 cfa8  SPRG2 cfa8  SPRG3 

  SPRG4  SPRG5   SPRG6   SPRG7 

  HSRR0  HSRR1 
   CFAR 
   LPCR 03d4f41f
DAR 0c8be5f8b8b0  DSISR 0a00

  In this case, NVIDIA GPU was pass-through'ed to the guest. 
  0004:04:00.0 3D controller [0302]: NVIDIA Corporation GV100 [Tesla V100 SXM2] 
[10de:1db1] (rev a1)
  0004:05:00.0 3D controller [0302]: NVIDIA Corporation GV100 [Tesla V100 SXM2] 
[10de:1db1] (rev a1)

  The initial few attempts of the guest reboot is successful, however in
  subsequent trials of rebooting in a loop, the guest crashes.

  == Versions Installed ==
  qemu   1:2.11+dfsg-1ubuntu7.8-1ibm3
  qemu-kvm 1:2.11+dfsg-1ubuntu7.9
  qemu-system-ppc 1:2.11+dfsg-1ubuntu7.8-1ibm3
  libvirt0:ppc64el 4.0.0-1ubuntu8.6
   
  Contact Information = Santwana Samantray/santwana.samant...@in.ibm.com 
   
  ---uname output---
  Linux ltcgen3 4.15.0-1016-ibm-gt #18-Ubuntu SMP Thu Feb 7 16:58:31 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = Witherspoon 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. Configure the guest with vfio pass-through.
  2. Start the guest.
  3. While the guest is in a running state, reboot the guest in a loop.
  [while true; do virsh reboot santwana_ubuntu; sleep 120; done]

  == Comment: #1 - SANTWANA SAMANTRAY  -
  2019-02-18 22:09:35 ==

  
  == Comment: #2 - SANTWANA SAMANTRAY  - 
2019-02-18 22:10:13 ==

  
  == Comment: #3 - SANTWANA SAMANTRAY  - 
2019-02-18 22:11:16 ==

  
  == Comment: #9 - Alexey Kardashevskiy  - 2019-02-20 
19:09:22 ==
  The patch from https://bugzilla.linux.ibm.com/show_bug.cgi?id=175550#c18 
should fix this issue too, this bz is a duplicate really.

  == Comment: #11 - SANTWANA SAMANTRAY  - 
2019-02-21 22:07:20 ==
  After installing the test kernel (https://ibm.ent.box.com/folder/67860346392) 
, the issue is still reproducible. The guest crashes during reboot operation.
  qemu: hardware error: 

[Kernel-packages] [Bug 1790788] Re: Customize 'crashkernel' parameter is not properly working

2019-03-08 Thread Frank Heimes
** Description changed:

  SRU Justification:
  --
  
  [Impact]
  
-  * While installing makedumpfile the "crashkernel=" argument is not
+  * While installing makedumpfile the "crashkernel=" argument is not
  properly set, hence dump is not triggered on reboot.
  
-  * Means the triggering of dumpfiles is currently not possible using
+  * Means the triggering of dumpfiles is currently not possible using
  makedumpfile.
  
-  * Dumpfiles are obviously only needed in rare cases, but if they are
+  * Dumpfiles are obviously only needed in rare cases, but if they are
  needed (e.g. in production environments) the situation is usually
  critical.
  
-  * Hence fixing this is needed to allow post-mortem analysis of a dumps.
+  * Hence fixing this is needed to allow post-mortem analysis of a dumps.
  
-  * The provided shell code snippet provides a fixed sed statement that
+  * The provided shell code snippet provides a fixed sed statement that
  makes sure that the kernel parameter is propoerly set.
  
  [Test Case]
  
-  * Create and boot a s390x (KVM virtual) machine
+  * Create and boot a s390x (KVM virtual) machine
  
-  * Install kdump-tools and makedumpfile
-Select 'yes' on question 'Should kdump-tools be enabled by default?' 
during installation
+  * Install kdump-tools and makedumpfile
+    Select 'yes' on question 'Should kdump-tools be enabled by default?' 
during installation
  
-  * [ Reboot system ]
+  * [ Reboot system ]
  
-  * Look for crashkernel line in zipl boot-loader
-grep crashkernel /etc/zipl.conf
-crashkernel line is missing in case this bug still exists
-one or more lines like this should be given:
-parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89 
crashkernel=196M
+  * Look for crashkernel line in zipl boot-loader
+    grep crashkernel /etc/zipl.conf
+    crashkernel line is missing in case this bug still exists
+    one or more lines like this should be given:
+    parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89 
crashkernel=196M
  
-  * One may further trigger a crash (for a full positiv test)
-sudo -s
-sysctl -w kernel.sysrq=1
-echo c > /proc/sysrq-trigger
-(in case this bug still exists the system will not come up again - check 
console in parallel)
+  * One may further trigger a crash (for a full positiv test)
+    sudo -s
+    sysctl -w kernel.sysrq=1
+    echo c > /proc/sysrq-trigger
+    (in case this bug still exists the system will not come up again - check 
console in parallel)
+Finally dump files should be visible in /var/crash
  
  [Regression Potential]
  
-  * The regression potential is very low, since:
+  * The regression potential is very low, since:
  
-  * it's limited to the zipl boot loader configuration file only
-and this means again it's on the s390x platform only (IBM Z)
+  * it's limited to the zipl boot loader configuration file only
+    and this means again it's on the s390x platform only (IBM Z)
  
-  * kdump-tools and makedumpfile are not installed by default and only used in 
debug situations
-hence only system where the package(s) got manually installed get updated
+  * kdump-tools and makedumpfile are not installed by default and only used in 
debug situations
+    hence only system where the package(s) got manually installed get updated
  
-  * The function is today broken anyway, hence it can actually only get
+  * The function is today broken anyway, hence it can actually only get
  better
  
-  * I successfully verified this in disco.
+  * I successfully verified this in disco.
  _
  
  Trying to use crashdump especially in a KVM machine.
  Installation looks fine and the reboot is triggered.
  But it does not work because the kernel does not have a 'crashkernel=' 
parameter.
  Nothing in /proc/cmdline:
  $ cat /proc/cmdline
  root=LABEL=cloudimg-rootfs
  
  Issue seems to be in adding the crashkernel line in this snippet:
  # Customize crashkernel= value according to architecture
  ARCH="$(arch)"
  DEF_PRESET="384M-:128M"
  case "$ARCH" in
     s390x)
    HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
    if test -z "$HAS_CRASHKERNEL"; then
   sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}" 
/etc/zipl.conf
   zipl
    fi
   CIO_IGNORE="$(cio_ignore -u -k)"
   sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
   sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}" 
$INITCONFFILE
  ;;
  esac
  
  (especially 1st sed stmt)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1790788

Title:
  Customize 'crashkernel' parameter is not properly working

Status in Ubuntu on IBM z Systems:

[Kernel-packages] [Bug 1790788] Re: Customize 'crashkernel' parameter is not properly working

2019-03-08 Thread Frank Heimes
SRU justification added - see bug description

** Description changed:

+ SRU Justification:
+ --
+ 
+ [Impact]
+ 
+  * While installing makedumpfile the "crashkernel=" argument is not
+ properly set, hence dump is not triggered on reboot.
+ 
+  * Means the triggering of dumpfiles is currently not possible using
+ makedumpfile.
+ 
+  * Dumpfiles are obviously only needed in rare cases, but if they are
+ needed (e.g. in production environments) the situation is usually
+ critical.
+ 
+  * Hence fixing this is needed to allow post-mortem analysis of a dumps.
+ 
+  * The provided shell code snippet provides a fixed sed statement that
+ makes sure that the kernel parameter is propoerly set.
+ 
+ [Test Case]
+ 
+  * Create and boot a s390x (KVM virtual) machine
+ 
+  * Install kdump-tools and makedumpfile
+Select 'yes' on question 'Should kdump-tools be enabled by default?' 
during installation
+ 
+  * [ Reboot system ]
+ 
+  * Look for crashkernel line in zipl boot-loader
+grep crashkernel /etc/zipl.conf
+crashkernel line is missing in case this bug still exists
+one or more lines like this should be given:
+parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89 
crashkernel=196M
+ 
+  * One may further trigger a crash (for a full positiv test)
+sudo -s
+sysctl -w kernel.sysrq=1
+echo c > /proc/sysrq-trigger
+(in case this bug still exists the system will not come up again - check 
console in parallel)
+ 
+ [Regression Potential]
+ 
+  * The regression potential is very low, since:
+ 
+  * it's limited to the zipl boot loader configuration file only
+and this means again it's on the s390x platform only (IBM Z)
+ 
+  * kdump-tools and makedumpfile are not installed by default and only used in 
debug situations
+hence only system where the package(s) got manually installed get updated
+ 
+  * The function is today broken anyway, hence it can actually only get
+ better
+ 
+  * I successfully verified this in disco.
+ _
+ 
  Trying to use crashdump especially in a KVM machine.
  Installation looks fine and the reboot is triggered.
  But it does not work because the kernel does not have a 'crashkernel=' 
parameter.
  Nothing in /proc/cmdline:
- $ cat /proc/cmdline 
+ $ cat /proc/cmdline
  root=LABEL=cloudimg-rootfs
  
  Issue seems to be in adding the crashkernel line in this snippet:
  # Customize crashkernel= value according to architecture
  ARCH="$(arch)"
  DEF_PRESET="384M-:128M"
  case "$ARCH" in
-s390x)
-   HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
-   if test -z "$HAS_CRASHKERNEL"; then
-  sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}" 
/etc/zipl.conf
-  zipl
-   fi
-  CIO_IGNORE="$(cio_ignore -u -k)"
-  sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
-  sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}" 
$INITCONFFILE
- ;;
+    s390x)
+   HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
+   if test -z "$HAS_CRASHKERNEL"; then
+  sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}" 
/etc/zipl.conf
+  zipl
+   fi
+  CIO_IGNORE="$(cio_ignore -u -k)"
+  sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
+  sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}" 
$INITCONFFILE
+ ;;
  esac
  
  (especially 1st sed stmt)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1790788

Title:
  Customize 'crashkernel' parameter is not properly working

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  New
Status in makedumpfile source package in Bionic:
  New
Status in makedumpfile source package in Cosmic:
  In Progress
Status in makedumpfile source package in Disco:
  Fix Released

Bug description:
  SRU Justification:
  --

  [Impact]

   * While installing makedumpfile the "crashkernel=" argument is not
  properly set, hence dump is not triggered on reboot.

   * Means the triggering of dumpfiles is currently not possible using
  makedumpfile.

   * Dumpfiles are obviously only needed in rare cases, but if they are
  needed (e.g. in production environments) the situation is usually
  critical.

   * Hence fixing this is needed to allow post-mortem analysis of a
  dumps.

   * The provided shell code snippet provides a fixed sed statement that
  makes sure that the kernel parameter is propoerly set.

  [Test Case]

   * Create and boot a s390x (KVM virtual) machine

   * Install kdump-tools and makedumpfile
 Select 'yes' on question 'Should kdump-tools be enabled by default?' 
during installation

   * [ Reboot system ]

   * Look for crashkernel line in zipl boot-loader
 grep crashkernel /etc/zipl.conf
 crashkernel line is 

[Kernel-packages] [Bug 1808743] Re: [Ubuntu 1810] Kdump fails to dump vmcore and enters initramfs inside Power9 KVM guest

2019-03-07 Thread Frank Heimes
Since it was in comment #9 verified that it now works as expected with
the in between available package (thanks to balamuruh...@in.ibm.com) -
I'm closing that ticket and set the status to Fix Released.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1808743

Title:
  [Ubuntu 1810] Kdump fails to dump vmcore and enters initramfs inside
  Power9 KVM guest

Status in The Ubuntu-power-systems project:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released

Bug description:
  Kdump fails to dump vmcore even with workaround suggested

  This issue is submitted to
  track on Power9 Guest where it uses file type qcow2 disk (virtio-scsi)

  
  Boot Log: (Attached full console log)

  [3.754031]32regs: 19616.000 MB/sec
  [3.794031]32regs_prefetch: 17280.000 MB/sec
  [3.834030]altivec   : 22480.000 MB/sec
  [3.834063] xor: using function: altivec (22480.000 MB/sec)
  done.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
done.
  Begin: Running /scripts/local-premount ... done.
  Begin: Waiting for root file system ... Begin: Running /scripts/local-block 
... mdadm: No devices listed in conf file were found.
  done.
  mdadm: No devices listed in conf file were found.
  mdadm: No devices listed in conf file were found.
  mdadm: No devices listed in conf file were found.
  done.
  Gave up waiting for root file system device.  Common problems:
   - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
   - Missing modules (cat /proc/modules; ls /dev)
  ALERT!  UUID=5e1fe9e9-cf03-4c73-adce-0e57676f98e0 does not exist.  Dropping 
to a shell!

  
  BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu4) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs)

  Contact Information = Balamuruhan S / balamuruh...@in.ibm.com 
   
  ---uname output---

  Guest Kernel: 4.18.0-11-generic
  Host Kernel:  4.18.0-11-generic
   
  Machine Type = Boston 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. Have a healthy KVM guest with Ubuntu 1810 with kernel 4.18.0-11-generic
  2. Install kdump, kexec and crash tools in the guest,
  # dpkg -l | grep crash
  ii  apport2.20.10-0ubuntu13.1 
 all  automatically generate crash reports for debugging
  ii  crash 7.2.3+real-1
 ppc64el  kernel debugging utility, allowing gdb like syntax
  ii  kdump-tools   1:1.6.4-2ubuntu1
 ppc64el  scripts and tools for automating kdump (Linux crash dumps)
  ii  linux-crashdump   4.18.0.11.12
 ppc64el  Linux kernel crashdump setup for the latest generic kernel
  ii  python3-apport2.20.10-0ubuntu13.1 
 all  Python 3 library for Apport crash report handling

  3. Ensure workaround suggested in Bug 172389 is followed by uncomment the 
`KDUMP_CMDLINE_APPEND`
  and change nr_cpus to maxcpus in /etc/default/kdump-tools config file,
   
  # cat /etc/default/kdump-tools | grep -i cmdline
  # KDUMP_CMDLINE - The default is to use the contents of /proc/cmdline.  
  # Set this variable to override /proc/cmdline.
  # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line 
  #KDUMP_CMDLINE=""
  KDUMP_CMDLINE_APPEND="1 maxcpus=1 systemd.unit=kdump-tools.service irqpoll 
noirqdistrib nousb reset_devices"

  4. restart the kdump tools service,
  # service kdump-tools restart
  # service kdump-tools status
  ? kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: active (exited) since Mon 2018-12-03 02:34:03 CST; 1 weeks 3 days 
ago
Process: 1560 ExecStart=/etc/init.d/kdump-tools start (code=exited, 
status=0/S
   Main PID: 1560 (code=exited, status=0/SUCCESS)

  Dec 03 02:34:02 ubuntu1810 systemd[1]: Starting Kernel crash dump capture 
servic
  Dec 03 02:34:02 ubuntu1810 kdump-tools[1560]: Starting kdump-tools:  * 
Creating 
  Dec 03 02:34:02 ubuntu1810 kdump-tools[1560]:  * Creating symlink 
/var/lib/kdump
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1560]: Modified 
cmdline:BOOT_IMAGE=/boot/
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1560]:  * loaded kdump kernel
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1678]: /sbin/kexec -p 
--command-line="BOO
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1679]: loaded kdump kernel
  Dec 03 02:34:03 ubuntu1810 systemd[1]: Started Kernel crash dump capture 
service

  5. check kdump-config is state is ready to dump,
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:

[Kernel-packages] [Bug 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures

2019-03-06 Thread Frank Heimes
** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Status: New => Triaged

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818854

Title:
  [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev
  failures

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  The vfio-ap driver will create a matrix device in sysfs without a subsystem 
link. This triggers failures in libudev that might also lead to libvirt errors 
(e.g. see 
https://www.redhat.com/archives/libvir-list/2019-February/msg00837.html)

  The proper fix is to add a subsystem link (e.g. by providing a dummy
  bus).

  
  A fix for that is upstream in master branch already for kernel 5.1

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=36360658eb5a6cf04bb9f2704d1e4ce54037ec99

  This  need to be applied to Bionic, Cosmic and Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1818854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1814684] Re: [19.04 FEAT] [LS1801] PCI Virtual function enablement

2019-03-06 Thread Frank Heimes
Just double-checked if everything ("PCI/IOV: Factor out
sriov_add_vfs()", "s390/pci: skip VF scanning", "s390/pci: map IOV
resources" and  "s390/pci: improve bar check") landed in disco-proposed
kernel "Ubuntu-5.0.0-7.8". Look good - like expected ("18f9e9d",
"7dc20ab", "9535cec" and "4a490e2").

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814684

Title:
  [19.04 FEAT] [LS1801] PCI Virtual function enablement

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed

Bug description:
  Description:
  The common code Linux kernel PCI bus driver performs initialization steps of 
PCI virtual functions (SRIOV) in an order that is incompatible with Z firmware 
requirements. As a result, virtual functions cannot be used properly. This item 
is about ensuring that PCI virtual functions can be correctly enabled in Linux.

  Tentativ target ; kernel 5.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814684/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805429] Re: [19.04 FEAT] Extended access controls for AP queue - kernel part

2019-03-06 Thread Frank Heimes
Just verified that commit "s390/zcrypt: multiple zcrypt device nodes
support" landed in disco-proposed kernel "Ubuntu-5.0.0-7.8" (as
"00fab23"). And config option CONFIG_ZCRYPT_MULTIDEVNODES is properly
enabled - looks good.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805429

Title:
  [19.04 FEAT] Extended access controls for AP queue - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed

Bug description:
  Update description:
  Provide a means to control which user/process can access which APQN, or in 
other words enable to grant users/applications access to different (sets of) 
crypto adapters and domains.
  While keeping existing interfaces for compatibility, allow to use both DAC 
(e.g. Unix file permissions) and MAC (e.g. LSM) methods.

  Please enable the following kernel config option:
 *  CONFIG_ZCRYPT_MULTIDEVNODES=y

  
  will be made available with kernel 4.20

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805429/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1788432] Re: 4.15 s390x kernel BUG at /build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

2019-03-06 Thread Frank Heimes
Just double checked and can confirm that the commits "virtio/s390: avoid race 
on vcdev->config" and "virtio/s390: fix race in ccw_io_helper()" landed in 
disco-proposed kernel "Ubuntu-5.0.0-7.8" (as "2448a29" and "78b1a52").
Hence changing disco entry to Fix Committed.

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788432

Title:
  4.15 s390x kernel BUG at /build/linux-
  Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  In Progress

Bug description:
  uname -a
  Linux ckingvm1 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 
s390x s390x s390x GNU/Linux

  and same for 4.15.0-29-generic and 4.17.0-8-generic

  Steps to reproduce this bug:

  git clone git://kernel.ubuntu.com/cking/stress-ng
  cd stress-ng
  make clean
  make

  And run with:

  ./stress-ng --sysfs 0 -t 60

  .. wait a few seconds and then:

  [  119.445891] [ cut here ]
  [  119.445898] kernel BUG at 
/build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!
  [  119.446093] illegal operation: 0001 ilc:1 [#3] SMP
  [  119.446100] Modules linked in: binfmt_misc zfs(PO) zunicode(PO) zavl(PO) 
icp(PO) isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic vfio_ccw sha512_s390 sha256_s390 vfio_mdev sha1_s390 sha_common 
mdev vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl 
lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 
raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 linear virtio_net crc32_vx_s390 virtio_blk
  [  119.446166] CPU: 1 PID: 5420 Comm: stress-ng-sysfs Tainted: P  DO  
   4.15.0-33-generic #36-Ubuntu
  [  119.446168] Hardware name: IBM 2964 N63 400 (KVM/Linux)
  [  119.446170] Krnl PSW : 12d313d3 405835bc 
(virtblk_cache_type_show+0x82/0x88 [virtio_blk])
  [  119.446177]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 
RI:0 EA:3
  [  119.446194] Krnl GPRS: de6dc5c2779af7d7 7ffaba20 0040 
6545
  [  119.446196]03ff800058da 6546 6bf537c0 
6b60a100
  [  119.446198] 00690648 7cc3de40 
7a74b000
  [  119.446202]03ff80008210  03ff800058da 
7ac1bce8
  [  119.446210] Krnl Code: 03ff80005912: ebbff0a80004  lmg 
%r11,%r15,168(%r15)
  [  119.446210]03ff80005918: c0f40560  brcl
15,3ff800063d8
  [  119.446210]   #03ff8000591e: a7f40001  brc 
15,3ff80005920
  [  119.446210]   >03ff80005922: 0707  bcr 0,%r7
  [  119.446210]03ff80005924: 0707  bcr 0,%r7
  [  119.446210]03ff80005926: 0707  bcr 0,%r7
  [  119.446210]03ff80005928: c004  brcl
0,3ff80005928
  [  119.446210]03ff8000592e: eb6ff0480024  stmg
%r6,%r15,72(%r15)
  [  119.446226] Call Trace:
  [  119.446229] ([<03ff800058da>] virtblk_cache_type_show+0x3a/0x88 
[virtio_blk])
  [  119.446234]  [<00690684>] dev_attr_show+0x3c/0x80
  [  119.446240]  [<00424ab4>] sysfs_kf_seq_show+0xbc/0x1a8
  [  119.446259]  [<003b048c>] seq_read+0xec/0x4c8
  [  119.446262]  [<003821ea>] vfs_read+0x8a/0x150
  [  119.446274]  [<00382786>] SyS_read+0x66/0xe0
  [  119.446278]  [<008e3028>] system_call+0xdc/0x2c8
  [  119.446279] Last Breaking-Event-Address:
  [  119.446281]  [<03ff8000591e>] virtblk_cache_type_show+0x7e/0x88 
[virtio_blk]
  [  119.446283]
  [  119.446284] ---[ end trace 2c2403d726047e4a ]---

  For  4.17.0-8-generic:
  [   25.170715] kernel BUG at drivers/block/virtio_blk.c:574!
  [   25.170795] illegal operation: 0001 ilc:1 [#1] SMP
  [   25.170797] Modules linked in: lttng_statedump(OE) lttng_clock(OE) 
lttng_lib_ring_buffer(OE) binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) 
isofs zcommon(PO) znvpair(PO) spl(O) ghash_s390 prng aes_s390 des_s390 
des_generic sha512_s390 sha256_s390 sha1_s390 sha_common vfio_ccw vfio_mdev 
mdev vfio_iommu_type1 vfio sch_fq_codel ib_iser rdma_cm iw_cm ib_cm nfsd 
ib_core auth_rpcgss iscsi_tcp nfs_acl lockd grace libiscsi_tcp libiscsi 
scsi_transport_iscsi sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor 
raid6_pq libcrc32c raid1 raid0 linear virtio_net virtio_blk crc32_vx_s390
  [   25.170835] CPU: 0 PID: 5590 Comm: 

[Kernel-packages] [Bug 1811259] Re: 4.20 kernel on s390x VM crashes

2019-03-06 Thread Frank Heimes
Just double checked and can confirm that the commits "virtio-balloon:
tweak config_changed implementation", "virtio: don't allocate vqs when
names[i] = NULL" and "virtio_pci: use queue idx instead of array idx to
set up the vq" landed in disco-proposed kernel "Ubuntu-5.0.0-7.8" (as
"bf4dc0b", "a229989" and "ddbeac0").

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811259

Title:
  4.20 kernel on s390x VM crashes

Status in Linux:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed

Bug description:
  Booting with  4.20.0-2-generic on a s390x 2 CPU VM we hit a panic:

  [0.394835] Linux version 4.20.0-2-generic (buildd@bos02-s390x-015) (gcc 
version 8.2.0 (Ubuntu 8.2.0-13ubuntu1)) #3-Ubuntu SMP Thu Jan 3 18:43:01 UTC 
2019 (Ubuntu 4.20.0-2.3-generic 4.20.0)
  [0.394838] setup.289988: Linux is running under KVM in 64-bit mode
  [0.394846] setup.b050d0: The maximum memory size is 2048MB
  [0.394866] numa.196305: NUMA mode: plain
  [0.394893] cpu.33a262: 2 configured CPUs, 0 standby CPUs
  [0.394999] Write protected kernel read-only data: 10464k
  [0.395034] Zone ranges:
  [0.395035]   DMA  [mem 0x-0x7fff]
  [0.395037]   Normal   empty
  [0.395038] Movable zone start for each node
  [0.395039] Early memory node ranges
  [0.395041]   node   0: [mem 0x-0x7fff]
  [0.395042] Initmem setup node 0 [mem 
0x-0x7fff]
  [0.413802] percpu: Embedded 25 pages/cpu @(ptrval) s62208 r8192 
d32000 u102400
  [0.413824] Built 1 zonelists, mobility grouping on.  Total pages: 516096
  [0.413825] Policy zone: DMA
  [0.413827] Kernel command line: root=LABEL=cloudimg-rootfs
  [0.450276] Memory: 2034164K/2097152K available (8116K kernel code, 1079K 
rwdata, 2344K rodata, 992K init, 772K bss, 62988K reserved, 0K cma-reserved)
  [0.450283] random: get_random_u64 called from kmem_cache_open+0x4c/0x4f0 
with crng_init=0
  [0.450432] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=3, Nodes=1
  [0.450434] ftrace: allocating 27385 entries in 107 pages
  [0.473325] rcu: Hierarchical RCU implementation.
  [0.473327] rcu:   RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=3.
  [0.473328]Tasks RCU enabled.
  [0.473329] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
  [0.473330] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=3
  [0.475371] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
  [0.475402] clocksource: tod: mask: 0x max_cycles: 
0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
  [0.475558] printk: console [ttyS1] enabled
  [0.475623] pid_max: default: 32768 minimum: 301
  [0.475658] LSM: Security Framework initializing
  [0.475660] Yama: becoming mindful.
  [0.475677] AppArmor: AppArmor initialized
  [0.476134] Dentry cache hash table entries: 262144 (order: 9, 2097152 
bytes)
  [0.476352] Inode-cache hash table entries: 131072 (order: 8, 1048576 
bytes)
  [0.476370] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
  [0.476377] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 
bytes)
  [0.476726] rcu: Hierarchical SRCU implementation.
  [0.476927] smp: Bringing up secondary CPUs ...
  [0.477181] smp: Brought up 1 node, 2 CPUs
  [0.477549] devtmpfs: initialized
  [0.477882] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
  [0.477902] futex hash table entries: 1024 (order: 6, 262144 bytes)
  [0.478105] NET: Registered protocol family 16
  [0.478134] audit: initializing netlink subsys (disabled)
  [0.478183] audit: type=2000 audit(1547122707.960:1): state=initialized 
audit_enabled=0 res=1
  [0.478222] Spectre V2 mitigation: execute trampolines
  [0.479205] HugeTLB registered 1.00 MiB page size, pre-allocated 0 pages
  [0.479623] SCSI subsystem initialized
  [0.479856] NetLabel: Initializing
  [0.479858] NetLabel:  domain hash size = 128
  [0.479859] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
  [0.479871] NetLabel:  unlabeled traffic allowed by default
  [0.507362] VFS: Disk quotas dquot_6.6.0
  [0.507378] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
  [0.507486] AppArmor: AppArmor Filesystem Enabled
  [0.507847] NET: Registered protocol family 2
  [0.507976] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 
16384 bytes)
  [0.507994] TCP established hash table entries: 16384 (order: 5, 131072 
bytes)
  [0.508126] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
  [0.508235] TCP: Hash tables 

[Kernel-packages] [Bug 1798776] Re: kvm_stat : missing python dependency

2019-03-06 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1798776

Title:
  kvm_stat : missing python dependency

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  After installing linux-tools-host, the included kvm_stat utility won't
  work:

  root@ubuntu:~# kvm_stat 
  -bash: /usr/bin/kvm_stat: /usr/bin/python: bad interpreter: No such file or 
directory

  Reason is that there is apparently no dependency on a python package
  from the linux-tools-host package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1798776/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1813934] Re: Vsock connect fails with ENODEV for large CID

2019-03-06 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1813934

Title:
  Vsock connect fails with ENODEV for large CID

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  - Problem Descripion:
  Kernel 4.19 introduced a bug in the Vsock protocol when using a large Context 
ID. 

  E.g.
  CID 0xfff000 works correctly but
  CID 0xfff001 fails with ENODEV when trying to connect to the listener.

  The issue now also shows up in Ubuntu 18.04 with 
   -> kernel 4.15.0-44-generic #47-Ubuntu 
  on x86_64 and s390x.

  It is already fixed upstream kernel by:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fbe078c37aba3088359c9256c1a1d0c3e39ee81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1813934/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818645] Re: Ubuntu18.04.01: [Power9] power8 Compat guest(RHEL7.6) crashes during guest boot with > 256G of memory (kernel/kvm)

2019-03-05 Thread Frank Heimes
Assuming that this happens with all guests with more than 256GB of
memory, since it's a KVM host kernel side issue.

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: ubuntu-power-systems
   Status: New => Triaged

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818645

Title:
  Ubuntu18.04.01: [Power9] power8 Compat guest(RHEL7.6) crashes during
  guest boot with > 256G of memory (kernel/kvm)

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2019-02-28 
04:38:22 ==
  ---Problem Description---
  Power8 Compat guest(RHEL 7.6) crashes during guest boot with > 256G of memory 
(kernel/kvm)
   
  Contact Information = sathe...@in.ibm.com 
   
  ---uname output---
  Host Kernel: 4.15.0-1016-ibm-gt

  ii  qemu-system-ppc1:2.11+dfsg-
  1ubuntu7.8-1ibm3   ppc64el  QEMU
  full system emulation binaries (ppc)

  ii  libvirt-bin4.0.0-1ubuntu8.6
  ppc64el  programs for the libvirt library

  Guest kernel: 3.10.0-957.5.1.el7.ppc64le (rhel7.6 zstream)
   
  Machine Type = power9 ppc64le 

   
  ---Steps to Reproduce---
   1. Boot a power8 compat guest with memory >256G
  virsh define avocado-vt-vm1;virsh start --console avocado-vt-vm1 (guest xml 
sosreport attached)
  Guest crashes while booting

  
  2019-02-28 10:36:44.752+: starting up libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100), qemu version: 2.11.1(Debian 
1:2.11+dfsg-1ubuntu7.8-1ibm3), hostname: cs-host-f37-ac922-3.pok.ibm.com
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-ppc64 -name 
guest=avocado-vt-vm1,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-avocado-vt-vm1/master-key.aes
 -machine pseries-2.11,accel=kvm,usb=off,dump-guest-core=off -m 264192 
-realtime mlock=off -smp 256,sockets=256,cores=1,threads=1 -uuid 
f4e14f88-bf1b-4cc3-b6d6-958d514d6c18 -display none -no-user-config -nodefaults 
-chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-15-avocado-vt-vm1/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device 
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive 
file=/home/sath/avocado-fvt-wrapper/data/avocado-vt/images/rhel76-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:fd:fe,bus=pci.0,addr=0x1 
-chardev pty,id=charserial0 -device 
spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 -chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-15-avocado-vt-vm1/org.qemu.guest_agent.0,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
  2019-02-28 10:36:44.759+: 19598: info : libvirt version: 4.0.0, package: 
1ubuntu8.6 (Christian Ehrhardt  Fri, 09 Nov 
2018 07:42:01 +0100)
  2019-02-28 10:36:44.759+: 19598: info : hostname: cs-host-f37-ac922-3
  2019-02-28 10:36:44.759+: 19598: info : virObjectUnref:350 : 
OBJECT_UNREF: obj=0x76d594111710
  2019-02-28T10:36:44.781703Z qemu-system-ppc64: -chardev pty,id=charserial0: 
char device redirected to /dev/pts/3 (label charserial0)
  2019-02-28T10:36:44.781945Z qemu-system-ppc64: warning: Number of SMP cpus 
requested (256) exceeds the recommended cpus supported by KVM (128)
  2019-02-28T10:36:44.781953Z qemu-system-ppc64: warning: Number of 
hotpluggable cpus requested (256) exceeds the recommended cpus supported by KVM 
(128)
  2019-02-28 10:37:18.060+: shutting down, reason=crashed
  2019-02-28T10:37:18.071969Z qemu-system-ppc64: terminating on signal 15 from 
pid 14056 (/usr/sbin/libvirtd)

   
  *Additional Instructions for sathe...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

  
  == Comment: #3 - Satheesh Rajendran  - 2019-02-28 
04:51:45 ==
  Possible Upstream fix: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=46dec40fb741f00f1864580130779aeeaf24fb3d

To manage 

[Kernel-packages] [Bug 1817832] Re: qemu crashes with `kvm_init_vcpu failed: Invalid argument` during guest boot cores >256

2019-02-26 Thread Frank Heimes
** Changed in: ubuntu-power-systems
 Assignee: Canonical Server Team (canonical-server) => Canonical Kernel 
Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1817832

Title:
  qemu crashes with `kvm_init_vcpu failed: Invalid argument` during
  guest boot cores >256

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  New
Status in linux source package in Cosmic:
  New

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2019-02-14 
23:48:15 ==
  ---Problem Description---
  qemu crashes with `kvm_init_vcpu failed: Invalid argument` during guest boot 
cores >256 but the error message is not clearly explains it.
   
  Contact Information = sathe...@in.ibm.com 
   
  ---uname output---
  4.15.0-1016-ibm-gt
   
  Machine Type = power9 ppc64le
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   # /usr/bin/qemu-system-ppc64 -smp 257 -enable-kvm -monitor stdio
  qemu-system-ppc64: warning: Number of SMP cpus requested (257) exceeds the 
recommended cpus supported by KVM (128)
  qemu-system-ppc64: warning: Number of hotpluggable cpus requested (257) 
exceeds the recommended cpus supported by KVM (128)
  QEMU 2.11.1 monitor - type 'help' for more information
  (qemu) kvm_init_vcpu failed: Invalid argument

  Expected Result:
  1. Guest should boot fine or
  2.  Proper error message stating cores >256 need to have thread>1 because 
smp=512 with threads=2 works fine like below

  # /usr/bin/qemu-system-ppc64 -smp 512,cores=256,threads=2 -enable-kvm 
-monitor stdio
  qemu-system-ppc64: warning: Number of SMP cpus requested (512) exceeds the 
recommended cpus supported by KVM (128)
  qemu-system-ppc64: warning: Number of hotpluggable cpus requested (512) 
exceeds the recommended cpus supported by KVM (128)
  QEMU 2.11.1 monitor - type 'help' for more information
  (qemu) VNC server running on ::1:5900
  (qemu) info status
  VM status: running

  
   
  Userspace tool common name: ii  qemu-system-ppc   
   1:2.11+dfsg-1ubuntu7.8-1ibm3   ppc64el  QEMU full system 
emulation binaries (ppc) 
   
  The userspace tool has the following bit modes: both 

  Userspace rpm: ii  qemu-system-ppc
  1:2.11+dfsg-1ubuntu7.8-1ibm3   ppc64el  QEMU full system
  emulation binaries (ppc)

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for sathe...@in.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.

  
  commit 1e175d2e07c71d9574f5b1c74523abca54e2654f
  Author: Sam Bobroff 
  Date:   Wed Jul 25 16:12:02 2018 +1000

  commit b5c6f7607b908b1445f2556c8d2f3b1ec5fc5aa8
  Author: Paul Mackerras 
  Date:   Thu Jul 26 15:38:41 2018 +1000

  commit 1ebe6b81ebdba8faf377d1d7d84ad9368e7a0bae
  Author: Paul Mackerras 
  Date:   Thu Jul 26 14:53:54 2018 +1000

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1817832/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1811470] Re: [witherspoon] removing module nouveau causes cpu hard lockup

2019-02-26 Thread Frank Heimes
** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811470

Title:
  [witherspoon] removing module nouveau causes cpu hard lockup

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Installed 18.04 and upgraded kernel to linux-image-generic-hwe-18.04
  (4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:03:47). Copied
  gv100 firmware to /lib/firmware/nvidia, removed and reloaded nouveau
  (modprobe -r and modprobe). Tried to remove nouveau again using
  modprobe -r and I see the trace below. After a while the modprobe -r
  command completed the module was removed successfully.

  [  618.185258] nouveau 0035:04:00.0: DRM: failed to idle channel 1 [DRM]
  [  630.314599] watchdog: CPU 4 self-detected hard LOCKUP @ ioread32+0x2c/0x170
  [  630.314601] watchdog: CPU 4 TB:415266697100, last heartbeat 
TB:410146341428 (1ms ago)
  [  630.314601] Modules linked in: nouveau(-) ofpart at24 cmdlinepart 
uio_pdrv_genirq ipmi_powernv ipmi_devintf powernv_flash uio mtd opal_prd 
ipmi_msghandler ibmpowernv vmx_crypto sch_fq_codel ib_iser rdma_cm iw_cm ib_cm 
ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables 
autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy 
async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops drm crct10dif_vpmsum ahci crc32c_vpmsum tg3 libahci 
drm_panel_orientation_quirks [last unloaded: nouveau]
  [  630.314629] CPU: 4 PID: 6623 Comm: modprobe Not tainted 4.18.0-13-generic 
#14~18.04.1-Ubuntu
  [  630.314630] NIP:  c0729afc LR: c0080f766990 CTR: 
c0729ad0
  [  630.314630] REGS: c03fffd87d80 TRAP: 0900   Not tainted  
(4.18.0-13-generic)
  [  630.314631] MSR:  9280b033   
CR: 44002824  XER: 
  [  630.314638] CFAR: c0080f7b2ac4 IRQMASK: 1
  [  630.314639] GPR00: c0080f7ad3f8 c03f6c1bb850 c178c200 
c00c8e7e
  [  630.314642] GPR04:    
0008
  [  630.314644] GPR08: c03fa800 7fff c00c8e7e 
c0080f7b2ab0
  [  630.314647] GPR12: c0729ad0 c03fa800 0001 

  [  630.314649] GPR16:   039a7cc60074 
039a7cc3c978
  [  630.314652] GPR20: 039a7cc60070  78448f88 

  [  630.314654] GPR24: 039a8bf40ee8  c0080f82dca0 
c03fed072098
  [  630.314657] GPR28: c000203968a2c290 c000203968840908 c000203968840900 
0001
  [  630.314660] NIP [c0729afc] ioread32+0x2c/0x170
  [  630.314660] LR [c0080f766990] nouveau_bo_rd32+0x48/0x70 [nouveau]
  [  630.314661] Call Trace:
  [  630.314662] [c03f6c1bb850] [c03f6c1bb890] 0xc03f6c1bb890 
(unreliable)
  [  630.314663] [c03f6c1bb880] [c03f6c1bb8b0] 0xc03f6c1bb8b0
  [  630.314664] [c03f6c1bb8a0] [c0080f7ad3f8] 
nv84_fence_read+0x40/0x60 [nouveau]
  [  630.314666] [c03f6c1bb8c0] [c0080f7aab3c] 
nouveau_fence_update+0x44/0x100 [nouveau]
  [  630.314667] [c03f6c1bb900] [c0080f7ab5d8] 
nouveau_fence_done+0x100/0x180 [nouveau]
  [  630.314668] [c03f6c1bb940] [c0080f7ab8c8] 
nouveau_fence_wait+0x90/0x150 [nouveau]
  [  630.314669] [c03f6c1bb970] [c0080f7a8f90] 
nouveau_channel_idle+0xd8/0x140 [nouveau]
  [  630.314670] [c03f6c1bba00] [c0080f75f75c] 
nouveau_accel_fini+0x74/0xe0 [nouveau]
  [  630.314671] [c03f6c1bba30] [c0080f75f8e8] 
nouveau_drm_unload+0x60/0x130 [nouveau]
  [  630.314672] [c03f6c1bba60] [c00813b1b118] 
drm_dev_unregister+0x70/0x160 [drm]
  [  630.314673] [c03f6c1bbaa0] [c00813b1b3f0] drm_put_dev+0x48/0xa0 
[drm]
  [  630.314675] [c03f6c1bbb10] [c0080f760f8c] 
nouveau_drm_device_remove+0x54/0x90 [nouveau]
  [  630.314676] [c03f6c1bbb50] [c07a746c] 
pci_device_remove+0x6c/0x120
  [  630.314677] [c03f6c1bbb90] [c08a7014] 
device_release_driver_internal+0x294/0x380
  [  630.314678] [c03f6c1bbbe0] [c08a719c] driver_detach+0x7c/0x140
  [  630.314679] [c03f6c1bbc20] [c08a5304] 
bus_remove_driver+0x84/0x170
  [  630.314680] [c03f6c1bbc90] [c08a7ef8] 
driver_unregister+0x48/0x90
  [  630.314681] [c03f6c1bbd00] [c07a52b8] 
pci_unregister_driver+0x38/0x150
  [  630.314682] [c03f6c1bbd50] [c0080f7af048] 
nouveau_drm_exit+0x30/0xfc08 [nouveau]
  [  630.314683] [c03f6c1bbd70] [c01e6b14] 
sys_delete_module+0x1d4/0x310
  [  630.314684] [c03f6c1bbe30] [c000b288] system_call+0x5c/0x70
  [  630.314685] Instruction dump:
  [  630.314686] 

[Kernel-packages] [Bug 1788098] Re: Avoid migration issues with aligned 2MB THB

2019-02-25 Thread Frank Heimes
** Changed in: linux (Ubuntu Bionic)
   Status: Invalid => New

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

** Changed in: ubuntu-power-systems
   Status: Invalid => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1788098

Title:
  Avoid migration issues with aligned 2MB THB

Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in qemu package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  New
Status in linux source package in Cosmic:
  Invalid

Bug description:
  FYI: This blocks bug 1781526 - once this one here is resolved we can
  go on with SRU considerations for 1781526

  --- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT---

  Hi, in some environments it was observed that this qemu patch to
  enable THP made it more likely to hit guest migration issues, however
  the following kernel patch resolves those migration issues:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=c066fafc595eef5ae3c83ae3a8305956b8c3ef15
  KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix()

  Once merged upstream, it would be good to include that change as well
  to avoid potential migration problems. Should I open a new bug for
  that or is it better to track here?

  Note Paelzer: I have not seen related migration issues myself, but it
  seems reasonable and confirmed by IBM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1788098/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1817097] Re: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices

2019-02-21 Thread Frank Heimes
** Package changed: linux (Ubuntu) => lvm2 (Ubuntu)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Canonical Foundations Team 
(canonical-foundations)

** Changed in: ubuntu-z-systems
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1817097

Title:
  pvmove causes file system corruption without notice upon move from 512
  -> 4096 logical block size devices

Status in Ubuntu on IBM z Systems:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  Problem Description---
  Summary
  ===
  Environment: IBM Z13 LPAR and z/VM Guest
   IBM Type: 2964 Model: 701 NC9
  OS:  Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x)
   Package: lvm2 version 2.02.176-4.1ubuntu3
  LVM: pvmove operation corrupts file system when using 4096 (4k) logical block 
size
   and default block size being 512 bytes in the underlying devices
  The problem is immediately reproducible.

  We see a real usability issue with data destruction as consequence - which is 
not acceptable.
  We expect 'pvmove' to fail with error in such situations to prevent fs 
destruction,
  which might possibly be overridden by a force flag.

  
  Details
  ===
  After a 'pvmove' operation is run to move a physical volume onto an ecrypted
  device with 4096 bytes logical block size we experience a file system 
corruption.
  There is no need for the file system to be mounted, but the problem surfaces
  differently if so.

  Either, the 'pvs' command after the pvmove shows
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
/dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument

  or

  a subsequent mount shows (after umount if the fs had previously been mounted 
as in our
  setup)
  mount: /mnt: wrong fs type, bad option, bad superblock on 
/dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error.

  A minimal setup of LVM using one volume group with one logical volume defined,
  based on one physical volume is sufficient to raise the problem. One more 
physical
  volume of the same size is needed to run the pvmove operation to. 

LV
 |
  VG: LOOP_VG [ ]
 |
  PV: /dev/loop0   -->   /dev/mapper/enc-loop
  ( backed by /dev/mapper/enc-loop )

  The physical volumes are backed by loopback devices (losetup) to base the
  problem report on, but we have seen the error on real SCSI multipath volumes
  also, with and without cryptsetup mapper devices in use.

  
  Further discussion
  ==
  https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html
  The problem does not occur on block devices with native size of 4k.
  E.g. DASDs, or file systems with mkfs -b 4096 option.

  
  Terminal output
  ===
  See attached file pvmove-error.txt

  
  Debug data
  ==
  pvmove was run with -dd (maximum debug level)
  See attached journal file.
   
  Contact Information = christian.r...@de.ibm.com 
   
  ---uname output---
  Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Type: 2964 Model: 701 NC9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1.) Create two image files of 500MB in size
  and set up two loopback devices with 'losetup -fP FILE'
  2.) Create one physical volume and one volume group 'LOOP_VG',
  and one logical volume 'VG'
  Run:
  pvcreate /dev/loop0
  vgcreate LOOP_VG /dev/loop0
  lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
  3.) Create a file system on the logical volume device:
  mkfs.ext4 /dev/mapper/LOOP_VG-LV
  4.) mount the file system created in the previous step to some empty 
available directory:
  mount /dev/mapper/LOOP_VG-LV /mnt
  5.) Set up a second physical volume, this time encrypted with LUKS2,
  and open the volume to make it available:
  cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1
  cryptsetup luksOpen /dev/loop1 enc-loop
  6.) Create the second physical volume, and add it to the LOOP_VG
  pvcreate /dev/mapper/enc-loop
  vgextend LOOP_VG /dev/mapper/enc-loop
  7.) Ensure the new physical volume is part of the volume group:
  pvs
  8.) Move the /dev/loop0 volume onto the encrypted volume with maximum debug 
option:
  pvmove -dd /dev/loop0 /dev/mapper/enc-loop
  9.) The previous step succeeds, but corrupts the file system on the logical 
volume
   We expect an error here. 
   There might be a command line flag to override used because 

[Kernel-packages] [Bug 1814684] Re: [19.04 FEAT] [LS1801] PCI Virtual function enablement

2019-02-20 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Incomplete => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1814684

Title:
  [19.04 FEAT] [LS1801] PCI Virtual function enablement

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed

Bug description:
  Description:
  The common code Linux kernel PCI bus driver performs initialization steps of 
PCI virtual functions (SRIOV) in an order that is incompatible with Z firmware 
requirements. As a result, virtual functions cannot be used properly. This item 
is about ensuring that PCI virtual functions can be correctly enabled in Linux.

  Tentativ target ; kernel 5.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1814684/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805429] Re: [19.04 FEAT] Extended access controls for AP queue - kernel part

2019-02-19 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Incomplete => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805429

Title:
  [19.04 FEAT] Extended access controls for AP queue - kernel part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed

Bug description:
  Update description:
  Provide a means to control which user/process can access which APQN, or in 
other words enable to grant users/applications access to different (sets of) 
crypto adapters and domains.
  While keeping existing interfaces for compatibility, allow to use both DAC 
(e.g. Unix file permissions) and MAC (e.g. LSM) methods.

  Please enable the following kernel config option:
 *  CONFIG_ZCRYPT_MULTIDEVNODES=y

  
  will be made available with kernel 4.20

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805429/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805429] Re: [19.04 FEAT] Extended access controls for AP queue - kernel part

2019-02-19 Thread Frank Heimes
** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805429

Title:
  [19.04 FEAT] Extended access controls for AP queue - kernel part

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Update description:
  Provide a means to control which user/process can access which APQN, or in 
other words enable to grant users/applications access to different (sets of) 
crypto adapters and domains.
  While keeping existing interfaces for compatibility, allow to use both DAC 
(e.g. Unix file permissions) and MAC (e.g. LSM) methods.

  Please enable the following kernel config option:
 *  CONFIG_ZCRYPT_MULTIDEVNODES=y

  
  will be made available with kernel 4.20

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805429/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1790125] Re: Ubuntu18.10 - Bring ocxl driver in 18.10 to same level as 18.04.1

2019-02-18 Thread Frank Heimes
** Changed in: linux (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1790125

Title:
  Ubuntu18.10 - Bring ocxl driver in 18.10 to same level as 18.04.1

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  == Comment: #0 - Frederic Barrat  - 2018-08-31 
02:41:58 ==
  ---Problem Description---
  bring ocxl driver in 18.10 to same level as in 18.04.1
   
  ---uname output---
  Linux zaiuslp14 4.15.0-24-generic #26-Ubuntu SMP Wed Jun 13 08:43:33 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux
   
  ---Additional Hardware Info---
  opencapi adapter needed to use ocxl driver 

   
  Machine Type = power9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---

   
  Contact Information = frederic.bar...@fr.ibm.com 
   
  Stack trace output:
   no
   
  Oops output:
   no
   
  System Dump Info:
The system is not configured to capture a system dump.
   
  *Additional Instructions for frederic.bar...@fr.ibm.com: 
  -Attach sysctl -a output output to the bug.

  == Comment: #1 - Frederic Barrat  - 2018-08-31 
02:48:24 ==
  An important fix for the ocxl driver (opencapi driver for POWER9) is missing 
in kernel 4.18. It was merged during the 4.19 merge window. The fix is already 
in 18.04.1, so it needs to be added to the 18.10 kernel to avoid regression.

  The commit ID is:
  d497ebf5fb3a026c0817f8c96cde578787f24093
  ocxl: Fix page fault handler in case of fault on dying process

  
  Could you add it to the kernel for 18.10? Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1790125/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1778854] Re: kvm_pr on power9 not loadable

2019-02-18 Thread Frank Heimes
** Tags added: reverse-proxy-bugzilla targetmilestone-inin1804

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1778854

Title:
  kvm_pr on power9 not loadable

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Confirmed
Status in qemu source package in Bionic:
  Invalid

Bug description:
  Hi,
  this might be the worst bug report ever, but there just isn't a lot more info 
available when the issue occurs.

  I tried to set up 2nd level KVM on a P9 machine with kvm_pr but I run into 
(this is the series on commands I used on P8 btw):
$ sudo modprobe kvm_pr
modprobe: ERROR: could not insert 'kvm_pr': Input/output error

  Unfortunately there is no dmesg message (not even with level set to
  debug) or anything like it, so I'm stuck asking if P9 does not work
  with kvm_pr at all or if there are other constraints one should know?

  Note: while no more a problem for kvm_hv on P9 I disabled SMT but the
  issue persists.

  Modinfo LGTM and matches the kernel:
  ubuntu@bionic-kvm:~$ modinfo kvm_pr
  filename:   
/lib/modules/4.15.0-23-generic/kernel/arch/powerpc/kvm/kvm-pr.ko
  alias:  devname:kvm
  alias:  char-major-10-232
  license:GPL
  srcversion: CE18B50FD03CB9D9C432700
  depends:kvm
  intree: Y
  name:   kvm_pr
  vermagic:   4.15.0-23-generic SMP mod_unload mprofile-kernel
  signat: PKCS#7
  signer: 
  sig_key:
  sig_hashalgo:   md4
  ubuntu@bionic-kvm:~$ uname -a
  Linux bionic-kvm 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  It feels more that I'm missing something than a bug, but in that case
  I have to ask what it is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1778854/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1808743] Re: [Ubuntu 1810] Kdump fails to dump vmcore and enters initramfs inside Power9 KVM guest

2019-02-18 Thread Frank Heimes
** Changed in: ubuntu-power-systems
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1808743

Title:
  [Ubuntu 1810] Kdump fails to dump vmcore and enters initramfs inside
  Power9 KVM guest

Status in The Ubuntu-power-systems project:
  Incomplete
Status in makedumpfile package in Ubuntu:
  Triaged

Bug description:
  Kdump fails to dump vmcore even with workaround suggested

  This issue is submitted to
  track on Power9 Guest where it uses file type qcow2 disk (virtio-scsi)

  
  Boot Log: (Attached full console log)

  [3.754031]32regs: 19616.000 MB/sec
  [3.794031]32regs_prefetch: 17280.000 MB/sec
  [3.834030]altivec   : 22480.000 MB/sec
  [3.834063] xor: using function: altivec (22480.000 MB/sec)
  done.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
done.
  Begin: Running /scripts/local-premount ... done.
  Begin: Waiting for root file system ... Begin: Running /scripts/local-block 
... mdadm: No devices listed in conf file were found.
  done.
  mdadm: No devices listed in conf file were found.
  mdadm: No devices listed in conf file were found.
  mdadm: No devices listed in conf file were found.
  done.
  Gave up waiting for root file system device.  Common problems:
   - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
   - Missing modules (cat /proc/modules; ls /dev)
  ALERT!  UUID=5e1fe9e9-cf03-4c73-adce-0e57676f98e0 does not exist.  Dropping 
to a shell!

  
  BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu4) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs)

  Contact Information = Balamuruhan S / balamuruh...@in.ibm.com 
   
  ---uname output---

  Guest Kernel: 4.18.0-11-generic
  Host Kernel:  4.18.0-11-generic
   
  Machine Type = Boston 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  1. Have a healthy KVM guest with Ubuntu 1810 with kernel 4.18.0-11-generic
  2. Install kdump, kexec and crash tools in the guest,
  # dpkg -l | grep crash
  ii  apport2.20.10-0ubuntu13.1 
 all  automatically generate crash reports for debugging
  ii  crash 7.2.3+real-1
 ppc64el  kernel debugging utility, allowing gdb like syntax
  ii  kdump-tools   1:1.6.4-2ubuntu1
 ppc64el  scripts and tools for automating kdump (Linux crash dumps)
  ii  linux-crashdump   4.18.0.11.12
 ppc64el  Linux kernel crashdump setup for the latest generic kernel
  ii  python3-apport2.20.10-0ubuntu13.1 
 all  Python 3 library for Apport crash report handling

  3. Ensure workaround suggested in Bug 172389 is followed by uncomment the 
`KDUMP_CMDLINE_APPEND`
  and change nr_cpus to maxcpus in /etc/default/kdump-tools config file,
   
  # cat /etc/default/kdump-tools | grep -i cmdline
  # KDUMP_CMDLINE - The default is to use the contents of /proc/cmdline.  
  # Set this variable to override /proc/cmdline.
  # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line 
  #KDUMP_CMDLINE=""
  KDUMP_CMDLINE_APPEND="1 maxcpus=1 systemd.unit=kdump-tools.service irqpoll 
noirqdistrib nousb reset_devices"

  4. restart the kdump tools service,
  # service kdump-tools restart
  # service kdump-tools status
  ? kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
pres
 Active: active (exited) since Mon 2018-12-03 02:34:03 CST; 1 weeks 3 days 
ago
Process: 1560 ExecStart=/etc/init.d/kdump-tools start (code=exited, 
status=0/S
   Main PID: 1560 (code=exited, status=0/SUCCESS)

  Dec 03 02:34:02 ubuntu1810 systemd[1]: Starting Kernel crash dump capture 
servic
  Dec 03 02:34:02 ubuntu1810 kdump-tools[1560]: Starting kdump-tools:  * 
Creating 
  Dec 03 02:34:02 ubuntu1810 kdump-tools[1560]:  * Creating symlink 
/var/lib/kdump
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1560]: Modified 
cmdline:BOOT_IMAGE=/boot/
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1560]:  * loaded kdump kernel
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1678]: /sbin/kexec -p 
--command-line="BOO
  Dec 03 02:34:03 ubuntu1810 kdump-tools[1679]: loaded kdump kernel
  Dec 03 02:34:03 ubuntu1810 systemd[1]: Started Kernel crash dump capture 
service

  5. check kdump-config is state is ready to dump,
  # kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr: 
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.18.0-11-generic
  kdump initrd: 
 

[Kernel-packages] [Bug 1813934] Re: Vsock connect fails with ENODEV for large CID

2019-02-18 Thread Frank Heimes
Thanks again, Peter.
I'm adjusting the tags accordingly ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1813934

Title:
  Vsock connect fails with ENODEV for large CID

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  - Problem Descripion:
  Kernel 4.19 introduced a bug in the Vsock protocol when using a large Context 
ID. 

  E.g.
  CID 0xfff000 works correctly but
  CID 0xfff001 fails with ENODEV when trying to connect to the listener.

  The issue now also shows up in Ubuntu 18.04 with 
   -> kernel 4.15.0-44-generic #47-Ubuntu 
  on x86_64 and s390x.

  It is already fixed upstream kernel by:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fbe078c37aba3088359c9256c1a1d0c3e39ee81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1813934/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1798776] Re: kvm_stat : missing python dependency

2019-02-15 Thread Frank Heimes
Successfully verified on bionic, too - see attachment.
Adjusting tags accordingly ...

** Attachment added: "verification_bionic.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798776/+attachment/5238882/+files/verification_bionic.txt

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1798776

Title:
  kvm_stat : missing python dependency

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  After installing linux-tools-host, the included kvm_stat utility won't
  work:

  root@ubuntu:~# kvm_stat 
  -bash: /usr/bin/kvm_stat: /usr/bin/python: bad interpreter: No such file or 
directory

  Reason is that there is apparently no dependency on a python package
  from the linux-tools-host package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1798776/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1784331] Re: [18.10 FEAT] zcrypt DD: introduce APQN tags to support deterministic driver binding

2019-02-14 Thread Frank Heimes
Bug is already Fix Released, so no further verification needed.
Adjusting tags accordingly ...

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784331

Title:
  [18.10 FEAT] zcrypt DD: introduce APQN tags to support deterministic
  driver binding

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  With the introduction of KVM crypto virtualization the driver bound to an AP 
queue device is no longer unique determined.
  This feature provides a deterministic hot plugging semantics of AP queues 
that may be bound to multiple drivers.
  In particular it enables to configure an AP queue (APQN) as being bound to a 
particular driver even if the associate HW gets intermittently lost and 
reconnected.

  Is planned as part of kernel 4.19. Therefore a backport to kernel 4.18
  will be required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1784331/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1807686] Re: efi-lockdown patch causes -EPERM for some debugfs files even though CONFIG_LOCK_DOWN_KERNEL is not set

2019-02-14 Thread Frank Heimes
Bug is already Fix Released, so no further verification needed.
Adjusting tags accordingly ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807686

Title:
  efi-lockdown patch causes -EPERM for some debugfs files even though
  CONFIG_LOCK_DOWN_KERNEL is not set

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  == Comment: #0 - Dominik Klein  - 2018-12-10 
03:58:10 ==
  There seems to be a bug in the efi-lockdown patch as applied on top of 
vanilla for Cosmic kernels:
  
http://kernel.ubuntu.com/git/ubuntu/ubuntu-cosmic.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986

  Also seems to be present for Disco as of today:
  
http://kernel.ubuntu.com/git/ubuntu/ubuntu-disco.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986

  The problem is that part of the patch modifies kernel behavior
  independently of CONFIG_LOCK_DOWN_KERNEL being set or not causing
  issues on two debugfs files on s390x.

  Vasily Gorbik has already analyzed the problem and has posted a proposed fix 
here:
  https://lkml.org/lkml/2018/11/21/634
  https://lkml.org/lkml/2018/11/21/635

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1807686/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1753424] Re: s390/crypto: Fix kernel crash on aes_s390 module remove

2019-02-14 Thread Frank Heimes
Ticket is already Fix Released - hence verification is no longer needed
- adjusting the tags ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1753424

Title:
  s390/crypto: Fix kernel crash on aes_s390 module remove

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  Upstream patch to fix the aes_s390 kernel module remove crash,
  introduced with kernel 4.15 rc1.

  Here is the patch to fix the kernel crash on aes_s390 kernel module removal.
  Please note that this patch is as of now not upstream available but in the 
s390 pipe for the next merge window (and so may be visible upstream with the 
start of the 4.17 development kernels).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1753424/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1734130] Re: [18.04 FEAT] Add kvm_stat from kernel tree

2019-02-14 Thread Frank Heimes
Ticket is already Fix Released - hence verification is no longer needed
- adjusting the tags ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1734130

Title:
  [18.04 FEAT] Add kvm_stat from kernel tree

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  Improves RAS characterics of systems running KVM by providing kvm_stat script:
  https://github.com/torvalds/linux/tree/master/tools/kvm/kvm_stat

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1734130/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1753708] Re: Ubuntu18.04:PowerPC - Set Transparent Huge Pages (THP) by default to "always"

2019-02-14 Thread Frank Heimes
Ticket is already Fix Released - hence verification is no longer needed
- adjusting the tags ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1753708

Title:
  Ubuntu18.04:PowerPC - Set Transparent Huge Pages (THP) by default to
  "always"

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  == Comment: #0 - Praveen K. Pandey  - 2018-03-06 
02:06:31 ==
  Problem Description :

  PowerPC systems running Ubuntu18.04 have Transparent Huge Pages (THP) 
  always set to "madvise". It should be by default set to "always". 

  Reproducible Step:

  1-  Install Ubuntu 18.04 on PowerPC box 
  2- cat /sys/kernel/mm/transparent_hugepage/enabled
  3- grep  "TRANSPARENT" /boot/config-$(uname -r)

  it is set to  madvise

  LOG:

  root@system:~# grep  "TRANSPARENT" /boot/config-$(uname -r)
  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
  CONFIG_TRANSPARENT_HUGEPAGE=y
  # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
  root@system:~# cat /sys/kernel/mm/transparent_hugepage/enabled
  always [madvise] never
  root@system:~# 

  Regards
  Praveen

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1753708/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1794346] Re: check and fix zkey required kernel modules locations in debs, udebs, and initramfs

2019-02-14 Thread Frank Heimes
Ticket is already Fix Released - hence verification is no longer needed
- adjusting the tags ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1794346

Title:
  check and fix zkey required kernel modules locations in debs, udebs,
  and initramfs

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released

Bug description:
  todo: check that these modules are included in the initramfs as well.

  === linux crypto-modules udeb task ==
  linux-modules-4.18.0-8-generic has:
  ./lib/modules/4.18.0-8-generic/kernel/arch/s390/crypto/paes_s390.ko
  ./lib/modules/4.18.0-8-generic/kernel/drivers/s390/crypto/pkey.ko
  ./lib/modules/4.18.0-8-generic/kernel/drivers/s390/crypto/zcrypt.ko
  ./lib/modules/4.18.0-8-generic/kernel/drivers/s390/crypto/zcrypt_cex2a.ko
  ./lib/modules/4.18.0-8-generic/kernel/drivers/s390/crypto/zcrypt_cex4.ko
  ./lib/modules/4.18.0-8-generic/kernel/drivers/s390/crypto/zcrypt_pcixcc.ko

  All of the above appear to be missing from the crypto-modules-4.18.0-8
  -generic-di, please ship them in crypto-modules udeb.

  To avoid discrepancies as to what crypto is supported by the installed
  system, versus d-i environment, it would be nice to make udebs and
  linux-modules packages roughly the same.

  Does it at all make sense to ship matching set of 
kernel/{arch,drivers}/s390/crypto/*.ko in crypto-modules udeb, as shilled in 
linux-modules deb?
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794346/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1762353] Re: [Ubuntu 18.04] cryptsetup: 'device-mapper: reload ioctl on failed' when setting up a second end-to-end encrypted disk

2019-02-14 Thread Frank Heimes
Ticket is already Fix Released - correcting the tags again ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1762353

Title:
  [Ubuntu 18.04] cryptsetup: 'device-mapper: reload ioctl on  failed'
  when setting up a second end-to-end encrypted disk

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Problem Description:
  Environment: z14 VM Guest system with one CEX6C CCA coprocessor
  in toleration mode (i.e. CEX6 HW presented as CEX5)
  OS: Ubuntu 18.04 Prerelease
  Setting up a second dm-crypt device using protected CCA paes-xts keys fails.
  The problem is reproducible.

  Details
  ===
  Setting up two or more plain end-to-end encrypted disks using 'cryptsetup'
  fails when using a cipher based on the protected key mechanism.
  The setup needs the paes and pkey modules loaded, the former providing the
  paes-xts-plain64 cipher (cat /proc/crpyto |grep paes).

  A second attempt to establish an end-to-end encrypted disk fails
  with : "device-mapper: reload ioctl on failed: No such file or directory."

  The problem is independent of the second encrypted disk being based on
  a second DASD or second partition on one DASD.

  ---uname output---
  Linux s3514004 4.13.0-25-generic #29-Ubuntu SMP Mon Jan 8 21:15:56 UTC 2018 
s390x s390x s390x GNU/Linux

  ---Steps to Reproduce---
  1.) The following cryptsetup statement works, and is the first one I issued.
  cryptsetup plainOpen --key-file securekey.bin --key-size 1024 --cipher 
paes-xts-plain64 /dev/disk/by-path/ccw-0.0.-part1 enc-pv1
  2.) After this successful statement, I issued the following:
  cryptsetup plainOpen --key-file securekey.bin --key-size 1024 --cipher 
paes-xts-plain64 /dev/disk/by-path/ccw-0.0.-part2 enc-pv2
  device-mapper: reload ioctl on failed: No such file or directory.

  See attached patch (comment #1) as fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1762353/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1762719] Re: System Z {kernel} UBUNTU18.04 wrong kernel config

2019-02-14 Thread Frank Heimes
Since this bug was already successfully verified, I'm adjusting the tags
accordingly ...

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1762719

Title:
  System Z {kernel} UBUNTU18.04 wrong kernel config

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Kernel config 4.15.0-13-generic #14 (and same for 4.15.0-15-generic)
  is not OK, because both security mechanisms nobp AND expoline are
  enabled:

  CONFIG_KERNEL_NOBP=y
  CONFIG_EXPOLINE=y
  # CONFIG_EXPOLINE_OFF is not set
  # CONFIG_EXPOLINE_MEDIUM is not set
  CONFIG_EXPOLINE_FULL=y

  If the kernel is compiled with a gcc that can generate expoline thunks
  the correct config is as follows:

  # CONFIG_KERNEL_NOBP is not set
  CONFIG_EXPOLINE=y
  # CONFIG_EXPOLINE_OFF is not set
  # CONFIG_EXPOLINE_MEDIUM is not set
  CONFIG_EXPOLINE_FULL=y

  Alternatively the auto-detection patch can be used which is upstream
  as of today:

  commit 6e179d64126b909f0b288fa63cdbf07c531e9b1d

  s390: add automatic detection of the spectre defense
  
  Automatically decide between nobp vs. expolines if the spectre_v2=auto
  kernel parameter is specified or CONFIG_EXPOLINE_AUTO=y is set.
  
  The decision made at boot time due to CONFIG_EXPOLINE_AUTO=y being set
  can be overruled with the nobp, nospec and spectre_v2 kernel parameters.
  
  If this patch is used, then the correct config is

  # CONFIG_KERNEL_NOBP is not set
  CONFIG_EXPOLINE=y
  # CONFIG_EXPOLINE_OFF is not set
  CONFIG_EXPOLINE_AUTO=y
  # CONFIG_EXPOLINE_FULL is not set

  This patch goes together with three others, so a total of four patches
  would be needed for the latest-and-greated solution:

  b2e2f43a01bace1a25bdbae04c9f9846882b727a
  6e179d64126b909f0b288fa63cdbf07c531e9b1d
  bc035599718412cfba9249aa713f90ef13f13ee9
  d424986f1d6b16079b3231db0314923f4f8deed1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1762719/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1813934] Re: Vsock connect fails with ENODEV for large CID

2019-02-12 Thread Frank Heimes
Many thanks Peter!
Adjusting tags accordingly ...

** Tags removed: verification-needed-cosmic
** Tags added: verification-done-cosmic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1813934

Title:
  Vsock connect fails with ENODEV for large CID

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  - Problem Descripion:
  Kernel 4.19 introduced a bug in the Vsock protocol when using a large Context 
ID. 

  E.g.
  CID 0xfff000 works correctly but
  CID 0xfff001 fails with ENODEV when trying to connect to the listener.

  The issue now also shows up in Ubuntu 18.04 with 
   -> kernel 4.15.0-44-generic #47-Ubuntu 
  on x86_64 and s390x.

  It is already fixed upstream kernel by:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fbe078c37aba3088359c9256c1a1d0c3e39ee81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1813934/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805245] Re: powerpc/powernv/pci: Work around races in PCI bridge enabling

2019-02-11 Thread Frank Heimes
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805245

Title:
  powerpc/powernv/pci: Work around races in PCI bridge enabling

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  SRU Justification
  =

  [Impact]

  An IBM OpenPower partner reports their system with a bunch of NVMe
  drives fails the NVMe init due to some drives taking PCIe EEH errors.

  [Fix]

  Pick patch db2173198b9513f7add8009f225afa1f1c79bcc6 upstream.

  [Testing]

  IBM reports that this patch fixes the user's issue.

  [Regression Potential]

  The patch is already in Cosmic (db33bbe77b9594133fecf0dc290322437170627f) and 
in some stable trees (1eb08e7b192d2c412175f607cf51449c916abd57 in 4.14.y).
  It only affects PowerPC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1805245/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1815470] Re: perf scripting python: Add ppc64le to audit uname list

2019-02-11 Thread Frank Heimes
** Package changed: kernel-package (Ubuntu) => linux (Ubuntu)

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => Medium

** Changed in: ubuntu-power-systems
   Status: New => Triaged

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1815470

Title:
  perf scripting python: Add ppc64le to audit uname list

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Paul A. Clarke  - 2017-08-31 12:16:56 ==
  ---Problem Description---
  "perf" package needs a fix to support "audit"-related functionality with 
python.  See 
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py?id=6fae8663c9940bcaa9edd8e21a9ae0f562789a3d

  The support is there for all other arches except ppc64le.  The patch
  is a one-line fix.

  Currently, Ubuntu doesn't python scripting in perf at all.  That is being 
tracked at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1707875.  So, 
this bug should depend on that.
   
  Contact Information = Paul Clarke/p...@us.ibm.com (submitter) 
   
  ---uname output---
  na
   
  Machine Type = na 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py?id=6fae8663c9940bcaa9edd8e21a9ae0f562789a3d
   
  Userspace tool common name: perf 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: linux-tools

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Paul Clarke/p...@us.ibm.com (submitter):
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1815470/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1798776] Re: kvm_stat : missing python dependency

2019-02-11 Thread Frank Heimes
Successfully verified after moving to latest kernel in proposed and installing 
corresponding linux-tools-host package - see attachment.
Adjusting tags accordingly ...

** Attachment added: "verification_cosmic.txt"
   
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1798776/+attachment/5237676/+files/verification_cosmic.txt

** Tags removed: verification-needed-cosmic
** Tags added: verification-done-cosmic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1798776

Title:
  kvm_stat : missing python dependency

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  After installing linux-tools-host, the included kvm_stat utility won't
  work:

  root@ubuntu:~# kvm_stat 
  -bash: /usr/bin/kvm_stat: /usr/bin/python: bad interpreter: No such file or 
directory

  Reason is that there is apparently no dependency on a python package
  from the linux-tools-host package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1798776/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1815057] Re: [UBUNTU] GCC Wrong code generate for floating point workloads Ubuntu 18.04

2019-02-07 Thread Frank Heimes
** Package changed: linux (Ubuntu) => gcc-8 (Ubuntu)

** Package changed: gcc-8 (Ubuntu) => gcc-7 (Ubuntu)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Matthias Klose (doko)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1815057

Title:
  [UBUNTU] GCC Wrong code generate for floating point workloads Ubuntu
  18.04

Status in Ubuntu on IBM z Systems:
  New
Status in gcc-7 package in Ubuntu:
  New

Bug description:
  An IBM Z GCC backend problem leads to wrong code being generated for
  some floating point workloads.

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856

  A patch has been committed to the GCC 7 and 8 upstream branch and
  needs to be picked up for the Ubuntu 18.04 compiler.

  https://gcc.gnu.org/viewcvs/gcc?view=revision=268551

  This change might require rebuilding floating point related packages.
  Although the actual problem is hard to trigger. I could only reproduce
  it in case if conversion introduces load on condition instructions in
  the ce2 pass. The testcase I've looked into came from the python scipy
  package which builds with -funroll-loops. The load on condition
  opportunity in that case was introduced with the RTL loop unrolling.
  This made the split1 pass to use the problematic splitter generating
  wrong code in the end.

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915738

  The patch has been picked up for gcc-8 8.2.0-18 already

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1815057/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1813934] Re: Vsock connect fails with ENODEV for large CID

2019-02-05 Thread Frank Heimes
This made it into the current kernel SRU cycle with the dates:

Kernel SRU cycle: 04-Feb through 24-Feb
    30-Jan Last day for kernel commits for this cycle
    04-Feb 08-Feb Kernel prep week    
11-Feb 22-Feb Bug verification & Regression testing
    25-Feb Release to -updates

Hence the plan is to have it available in the release pocket by Feb the 25th.
But it will already be earlier available via proposed.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1813934

Title:
  Vsock connect fails with ENODEV for large CID

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed

Bug description:
  - Problem Descripion:
  Kernel 4.19 introduced a bug in the Vsock protocol when using a large Context 
ID. 

  E.g.
  CID 0xfff000 works correctly but
  CID 0xfff001 fails with ENODEV when trying to connect to the listener.

  The issue now also shows up in Ubuntu 18.04 with 
   -> kernel 4.15.0-44-generic #47-Ubuntu 
  on x86_64 and s390x.

  It is already fixed upstream kernel by:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fbe078c37aba3088359c9256c1a1d0c3e39ee81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1813934/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1802514] Re: [19.04 FEAT] KVM : Support for configurable virtio-crypto

2019-02-04 Thread Frank Heimes
I verified that these two patches landed in the current 4.19 kernel of
disco (in release pocket now) - hence changing ticket to Fix Released.

** Changed in: ubuntu-z-systems
 Assignee: Skipper Bug Screeners (skipper-screen-team) => Frank Heimes 
(frank-heimes)

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

** Changed in: ubuntu-z-systems
   Status: Triaged => Fix Released

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1802514

Title:
  [19.04 FEAT] KVM : Support for configurable virtio-crypto

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Description: Enable KVM guests to use the virtio-crypto device to
  perform all crypto algorithms provided by the hypervisor crypto
  backend. This is done by implementing a handshake between the guest
  driver and host backend.

  Business Value: Increased flexibility by decoupling guest and host
  virtio-crypto capabilities and better compatibility between guest and
  host in the case of software upgrades.

  
  kernel 4.19:
  C: crypto: virtio - Read crypto services and algorithm masks [b551bac14a]
  C: crypto: virtio - Register an algo only if it's supported [d0d859bb87]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1802514/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805802] Re: [UBUNTU] qeth: fix length check in SNMP processing

2019-02-04 Thread Frank Heimes
This patch already landed in disco's Ubuntu-4.19.0-9.10 and since linux-
generic 4.19.0.12.13 landed in the disco release pocket today, I change
the disco entry from Fix Committed to Fix Released.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805802

Title:
  [UBUNTU] qeth: fix length check in SNMP processing

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  == SRU Justification ==
  The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.

  
  == Fix ==
  9a764c1e5968 ("s390/qeth: fix length check in SNMP processing")

  == Regression Potential ==
  Low.  Changes limited to s390.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.


  
  == Original bug description ==

  Description:  qeth: fix length check in SNMP processing
  Symptom:  Undefined behaviour.
  Problem:  The response for a SNMP request can consist of multiple parts,
    which the cmd callback stages into a kernel buffer until all
    parts have been received. If the callback detects that the
    staging buffer provides insufficient space, it bails out with
    error.
    This processing is buggy for the first part of the response -
    while it initially checks for a length of 'data_len', it later
    copies an additional amount of
    'offsetof(struct qeth_snmp_cmd, data)' bytes.
  Solution: Fix the calculation of 'data_len' for the first part of the
    response.
  Upstream-ID:  9a764c1e59684c0358e16ccaafd870629f2cfe67

  Should be applied to all Ubuntu Releases in Service

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805802/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805802] Re: [UBUNTU] qeth: fix length check in SNMP processing

2019-02-04 Thread Frank Heimes
Just verified that this patch already landed in disco kernel
Ubuntu-4.19.0-9.10, hence changing to Fix Released since we have linux-
generic 4.19.0.12.13 in disco as of today.

** Changed in: linux (Ubuntu Disco)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805802

Title:
  [UBUNTU] qeth: fix length check in SNMP processing

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  == SRU Justification ==
  The response for a SNMP request can consist of multiple parts,
which the cmd callback stages into a kernel buffer until all
parts have been received. If the callback detects that the
staging buffer provides insufficient space, it bails out with
error.
This processing is buggy for the first part of the response -
while it initially checks for a length of 'data_len', it later
copies an additional amount of
'offsetof(struct qeth_snmp_cmd, data)' bytes.

  
  == Fix ==
  9a764c1e5968 ("s390/qeth: fix length check in SNMP processing")

  == Regression Potential ==
  Low.  Changes limited to s390.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.


  
  == Original bug description ==

  Description:  qeth: fix length check in SNMP processing
  Symptom:  Undefined behaviour.
  Problem:  The response for a SNMP request can consist of multiple parts,
    which the cmd callback stages into a kernel buffer until all
    parts have been received. If the callback detects that the
    staging buffer provides insufficient space, it bails out with
    error.
    This processing is buggy for the first part of the response -
    while it initially checks for a length of 'data_len', it later
    copies an additional amount of
    'offsetof(struct qeth_snmp_cmd, data)' bytes.
  Solution: Fix the calculation of 'data_len' for the first part of the
    response.
  Upstream-ID:  9a764c1e59684c0358e16ccaafd870629f2cfe67

  Should be applied to all Ubuntu Releases in Service

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805802/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1811259] Re: 4.20 kernel on s390x VM crashes

2019-02-04 Thread Frank Heimes
Info: Smallest common upstream kernel level that includes all these 3
patches is v5.0-rc3

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1811259

Title:
  4.20 kernel on s390x VM crashes

Status in Linux:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed

Bug description:
  Booting with  4.20.0-2-generic on a s390x 2 CPU VM we hit a panic:

  [0.394835] Linux version 4.20.0-2-generic (buildd@bos02-s390x-015) (gcc 
version 8.2.0 (Ubuntu 8.2.0-13ubuntu1)) #3-Ubuntu SMP Thu Jan 3 18:43:01 UTC 
2019 (Ubuntu 4.20.0-2.3-generic 4.20.0)
  [0.394838] setup.289988: Linux is running under KVM in 64-bit mode
  [0.394846] setup.b050d0: The maximum memory size is 2048MB
  [0.394866] numa.196305: NUMA mode: plain
  [0.394893] cpu.33a262: 2 configured CPUs, 0 standby CPUs
  [0.394999] Write protected kernel read-only data: 10464k
  [0.395034] Zone ranges:
  [0.395035]   DMA  [mem 0x-0x7fff]
  [0.395037]   Normal   empty
  [0.395038] Movable zone start for each node
  [0.395039] Early memory node ranges
  [0.395041]   node   0: [mem 0x-0x7fff]
  [0.395042] Initmem setup node 0 [mem 
0x-0x7fff]
  [0.413802] percpu: Embedded 25 pages/cpu @(ptrval) s62208 r8192 
d32000 u102400
  [0.413824] Built 1 zonelists, mobility grouping on.  Total pages: 516096
  [0.413825] Policy zone: DMA
  [0.413827] Kernel command line: root=LABEL=cloudimg-rootfs
  [0.450276] Memory: 2034164K/2097152K available (8116K kernel code, 1079K 
rwdata, 2344K rodata, 992K init, 772K bss, 62988K reserved, 0K cma-reserved)
  [0.450283] random: get_random_u64 called from kmem_cache_open+0x4c/0x4f0 
with crng_init=0
  [0.450432] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=3, Nodes=1
  [0.450434] ftrace: allocating 27385 entries in 107 pages
  [0.473325] rcu: Hierarchical RCU implementation.
  [0.473327] rcu:   RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=3.
  [0.473328]Tasks RCU enabled.
  [0.473329] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
  [0.473330] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=3
  [0.475371] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
  [0.475402] clocksource: tod: mask: 0x max_cycles: 
0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
  [0.475558] printk: console [ttyS1] enabled
  [0.475623] pid_max: default: 32768 minimum: 301
  [0.475658] LSM: Security Framework initializing
  [0.475660] Yama: becoming mindful.
  [0.475677] AppArmor: AppArmor initialized
  [0.476134] Dentry cache hash table entries: 262144 (order: 9, 2097152 
bytes)
  [0.476352] Inode-cache hash table entries: 131072 (order: 8, 1048576 
bytes)
  [0.476370] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
  [0.476377] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 
bytes)
  [0.476726] rcu: Hierarchical SRCU implementation.
  [0.476927] smp: Bringing up secondary CPUs ...
  [0.477181] smp: Brought up 1 node, 2 CPUs
  [0.477549] devtmpfs: initialized
  [0.477882] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
  [0.477902] futex hash table entries: 1024 (order: 6, 262144 bytes)
  [0.478105] NET: Registered protocol family 16
  [0.478134] audit: initializing netlink subsys (disabled)
  [0.478183] audit: type=2000 audit(1547122707.960:1): state=initialized 
audit_enabled=0 res=1
  [0.478222] Spectre V2 mitigation: execute trampolines
  [0.479205] HugeTLB registered 1.00 MiB page size, pre-allocated 0 pages
  [0.479623] SCSI subsystem initialized
  [0.479856] NetLabel: Initializing
  [0.479858] NetLabel:  domain hash size = 128
  [0.479859] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
  [0.479871] NetLabel:  unlabeled traffic allowed by default
  [0.507362] VFS: Disk quotas dquot_6.6.0
  [0.507378] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
  [0.507486] AppArmor: AppArmor Filesystem Enabled
  [0.507847] NET: Registered protocol family 2
  [0.507976] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 
16384 bytes)
  [0.507994] TCP established hash table entries: 16384 (order: 5, 131072 
bytes)
  [0.508126] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
  [0.508235] TCP: Hash tables configured (established 16384 bind 16384)
  [0.508269] UDP hash table entries: 1024 (order: 3, 32768 bytes)
  [0.508287] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
  [0.508336] NET: Registered protocol family 

[Kernel-packages] [Bug 1812822] Re: Guest crashed when detaching the ovs interface device

2019-02-04 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1812822

Title:
  Guest crashed when detaching the ovs interface device

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete
Status in qemu package in Ubuntu:
  Incomplete

Bug description:
  
   When detaching one openvswitch interface device with virsh detach-device, if 
the port has been deleted from the ovs and the interface device has been 
deleted. The virsh detach-device will fail with "error: Unable to read from 
monitor: Connection reset by peer", the qemu is terminated and the log shows " 
UNSETVNETLE ioctl() failed, File descriptor in bad state".  

  
  [Background] This error is originally found from the openstack KVM CI tempest 
test.  By investigating I found it's introduced by one ovs-vif patch, which 
deletes the ovs port and delete the interface before detaching the device.  You 
can find the commit from https://bugs.launchpad.net/os-vif/+bug/1801072

  
  Reproduced:

  
     root@:~#  ovs-vsctl del-port br0 tap9273235a-dd
     root@:~#  ip link del tap9273235a-dd

  
  The interface device tap9273235a-dd has been removed from the host(ifconfg, 
ovs-vsctl show)  and can be found in the guest.(logon the guest, ip a  it's in 
down state)

  
  root@:~# virsh detach-device kvm net.xml
  error: Failed to detach device from net.xml
  error: Unable to read from monitor: Connection reset by peer

  
  The qemu has terminated and the log in /var/log/libvirt/qemu/kvm.log
  TUNSETVNETLE ioctl() failed: File descriptor in bad state.
  2019-01-18 08:16:11.304+: shutting down, reason=crashed

  
  It seems the qemu tried to handle this interface, but in fact it has been 
deleted. qemu couldn't read the file and give the error.
  But I don't think the guest should be crashed directly for the file 
descriptor error. 



  
  Environment:
  Ubuntu 16.04.5 LTS
  Linux (EC12) 4.4.0-141-generic
  QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5~cloud0)
  libvirtd (libvirt) 4.0.0


  
  net.xml

  
   
      
      
      
    
      
      
    
    
    
    
    


  
  kvm.xml

  
  
    kvm
    59f71b47-16e4-401d-9d33-30bc1605a84a
    524288
    524288
    1
    
      /machine
    
    
      hvm
      
    
    
      
    
    
    destroy
    restart
    destroy
    
      /usr/bin/qemu-system-s390x
      
    
    
    
    
    
    
      
      
    
    
    
      
      
    
    
      
      
    
    
      libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a
      libvirt-59f71b47-16e4-401d-9d33-30bc1605a84a
    
    
      +0:+0
      +0:+0
    
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1812822/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1799184] Re: [18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic driver binding

2019-02-04 Thread Frank Heimes
Just verified that the 3 patches (bug description / SRU template) are included 
in kernel 4.19 and since 4.19 laded in disco proposed today, I'm changing the 
kernel entry to Fix Released (code is available in cosmic, too).
Changing project entry to Fix Released, too.

** Changed in: linux (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1799184

Title:
  [18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic
  driver binding

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  == SRU Justification ==

  APQN tags in the zcrypt device driver are required to support
  deterministic driver binding

  With the introduction of KVM hw crypto virtualization (on s390x) the driver 
bound to an AP queue device is no longer unique determined.
  Therefore a deterministic hot plugging semantics of AP queues that may be 
bound to multiple drivers is needed.
  With the three listed commits here it will be possible to configure an AP 
queue (APQN) as being bound to a particular driver even if the associate hw 
gets intermittently lost and reconnected.

  == Fixes ==

  ac2b96f351d7d222 ("s390/zcrypt: code beautify")
  7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
  3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask and 
aqmask")

  == Patches ==

  Git-commit: ac2b96f351d7d222
  
https://github.com/torvalds/linux/commit/ac2b96f351d7d222c46e524feca03005f3fa8d75
  Author: Harald Freudenberger 
  Date:   Fri Aug 17 12:36:01 2018 +0200
  s390/zcrypt: code beautify
  Code beautify by following most of the checkpatch suggestions:
   - SPDX license identifier line complains by checkpatch
   - missing space or newline complains by checkpatch
   - octal numbers for permssions complains by checkpatch
   - renaming of static sysfs functions complains by checkpatch
   - fix of block comment complains by checkpatch
   - fix printf like calls where function name instead of %s __func__
     was used
   - __packed instead of __attribute__((packed))
   - init to zero for static variables removed
   - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros

  No functional code changes or API changes!

  Signed-off-by: Harald Freudenberger 
  Signed-off-by: Martin Schwidefsky 

  ===

  Git-commit 7e0bdbe5c21cb831
  
https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
  Author: Harald Freudenberger 
  Date:   Fri Jul 20 08:36:53 2018 +0200
  s390/zcrypt: AP bus support for alternate driver(s)
  The current AP bus, AP devices and AP device drivers implementation
  uses a clearly defined mapping for binding AP devices to AP device
  drivers. So for example a CEX6C queue will always be bound to the
  cex4queue device driver.

  The Linux Device Driver model has no sensitivity for more than one
  device driver eligible for one device type. If there exist more than
  one drivers matching to the device type, simple all drivers are tried
  consecutively.  There is no way to determine and influence the probing
  order of the drivers.

  With KVM there is a need to provide additional device drivers matching
  to the very same type of AP devices. With a simple implementation the
  KVM drivers run in competition to the regular drivers. Whichever
  'wins' a device depends on build order and implementation details
  within the common Linux Device Driver Model and is not
  deterministic. However, a userspace process could figure out which
  device should be bound to which driver and sort out the correct
  binding by manipulating attributes in the sysfs.

  If for security reasons a AP device must not get bound to the 'wrong'
  device driver the sorting out has to be done within the Linux kernel
  by the AP bus code. This patch modifies the behavior of the AP bus
  for probing drivers for devices in a way that two sets of drivers are
  usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a
  subset of the APQN range for 'usable by the ap bus and the default
  drivers' or 'not usable by the default drivers and thus available for
  alternate drivers like vfio-xxx'. So an APQN which is addressed by
  this masking only the default drivers will be probed. In contrary an
  APQN which is not addressed by the masks will never be probed and
  bound to default drivers but onny to alternate drivers.

  Eventually the two masks give a way to divide the range of APQNs into
  two pools: one pool of APQNs used by the AP bus and the default
  drivers and thus via zcrypt drivers available to the userspace of the
  system. And another pool where no zcrypt drivers are bound to and
  which can be used by alternate 

[Kernel-packages] [Bug 1799184] Re: [18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic driver binding

2019-02-04 Thread Frank Heimes
Just verified that the 3 patches (bug description / SRU template) are
included in kernel 4.19 and since 4.19 laded in disco proposed today,
I'm changing the kernel entry to Fix Committed (code is available in
cosmic, too).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1799184

Title:
  [18.04 FEAT] zcrypt DD: introduce APQN tags to support deterministic
  driver binding

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  == SRU Justification ==

  APQN tags in the zcrypt device driver are required to support
  deterministic driver binding

  With the introduction of KVM hw crypto virtualization (on s390x) the driver 
bound to an AP queue device is no longer unique determined.
  Therefore a deterministic hot plugging semantics of AP queues that may be 
bound to multiple drivers is needed.
  With the three listed commits here it will be possible to configure an AP 
queue (APQN) as being bound to a particular driver even if the associate hw 
gets intermittently lost and reconnected.

  == Fixes ==

  ac2b96f351d7d222 ("s390/zcrypt: code beautify")
  7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
  3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask and 
aqmask")

  == Patches ==

  Git-commit: ac2b96f351d7d222
  
https://github.com/torvalds/linux/commit/ac2b96f351d7d222c46e524feca03005f3fa8d75
  Author: Harald Freudenberger 
  Date:   Fri Aug 17 12:36:01 2018 +0200
  s390/zcrypt: code beautify
  Code beautify by following most of the checkpatch suggestions:
   - SPDX license identifier line complains by checkpatch
   - missing space or newline complains by checkpatch
   - octal numbers for permssions complains by checkpatch
   - renaming of static sysfs functions complains by checkpatch
   - fix of block comment complains by checkpatch
   - fix printf like calls where function name instead of %s __func__
     was used
   - __packed instead of __attribute__((packed))
   - init to zero for static variables removed
   - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros

  No functional code changes or API changes!

  Signed-off-by: Harald Freudenberger 
  Signed-off-by: Martin Schwidefsky 

  ===

  Git-commit 7e0bdbe5c21cb831
  
https://github.com/torvalds/linux/commit/7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
  Author: Harald Freudenberger 
  Date:   Fri Jul 20 08:36:53 2018 +0200
  s390/zcrypt: AP bus support for alternate driver(s)
  The current AP bus, AP devices and AP device drivers implementation
  uses a clearly defined mapping for binding AP devices to AP device
  drivers. So for example a CEX6C queue will always be bound to the
  cex4queue device driver.

  The Linux Device Driver model has no sensitivity for more than one
  device driver eligible for one device type. If there exist more than
  one drivers matching to the device type, simple all drivers are tried
  consecutively.  There is no way to determine and influence the probing
  order of the drivers.

  With KVM there is a need to provide additional device drivers matching
  to the very same type of AP devices. With a simple implementation the
  KVM drivers run in competition to the regular drivers. Whichever
  'wins' a device depends on build order and implementation details
  within the common Linux Device Driver Model and is not
  deterministic. However, a userspace process could figure out which
  device should be bound to which driver and sort out the correct
  binding by manipulating attributes in the sysfs.

  If for security reasons a AP device must not get bound to the 'wrong'
  device driver the sorting out has to be done within the Linux kernel
  by the AP bus code. This patch modifies the behavior of the AP bus
  for probing drivers for devices in a way that two sets of drivers are
  usable. Two new bitmasks 'apmask' and 'aqmask' are used to mark a
  subset of the APQN range for 'usable by the ap bus and the default
  drivers' or 'not usable by the default drivers and thus available for
  alternate drivers like vfio-xxx'. So an APQN which is addressed by
  this masking only the default drivers will be probed. In contrary an
  APQN which is not addressed by the masks will never be probed and
  bound to default drivers but onny to alternate drivers.

  Eventually the two masks give a way to divide the range of APQNs into
  two pools: one pool of APQNs used by the AP bus and the default
  drivers and thus via zcrypt drivers available to the userspace of the
  system. And another pool where no zcrypt drivers are bound to and
  which can be used by alternate drivers (like vfio-xxx) for their
  needs. This division is hot-plug save and makes sure a APQN assigned
  to an alternate driver is at no time somehow exploitable by the wrong
  party.

  The two masks are 

[Kernel-packages] [Bug 1807686] Re: efi-lockdown patch causes -EPERM for some debugfs files even though CONFIG_LOCK_DOWN_KERNEL is not set

2019-02-04 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1807686

Title:
  efi-lockdown patch causes -EPERM for some debugfs files even though
  CONFIG_LOCK_DOWN_KERNEL is not set

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  == Comment: #0 - Dominik Klein  - 2018-12-10 
03:58:10 ==
  There seems to be a bug in the efi-lockdown patch as applied on top of 
vanilla for Cosmic kernels:
  
http://kernel.ubuntu.com/git/ubuntu/ubuntu-cosmic.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986

  Also seems to be present for Disco as of today:
  
http://kernel.ubuntu.com/git/ubuntu/ubuntu-disco.git/commit/fs/debugfs/file.c?id=a1ba65da9ceae481c154bfd1a2c1550e4566d986

  The problem is that part of the patch modifies kernel behavior
  independently of CONFIG_LOCK_DOWN_KERNEL being set or not causing
  issues on two debugfs files on s390x.

  Vasily Gorbik has already analyzed the problem and has posted a proposed fix 
here:
  https://lkml.org/lkml/2018/11/21/634
  https://lkml.org/lkml/2018/11/21/635

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1807686/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1805414] Re: [Ubuntu] kernel: zcrypt: reinit ap queue state machine

2019-02-04 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805414

Title:
  [Ubuntu] kernel: zcrypt: reinit ap queue state machine

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux source package in Disco:
  Fix Released

Bug description:
  == SRU Justification ==
  The vfio device driver when receiving an ap queue device does
additional resets thereby removing the registration for
interrupts for the ap device done by the ap bus core
code. So when later the vfio driver releases the device and
one of the default zcrypt drivers takes care of the device
the interrupt registration needs to get renewed. The current
code does no renew and result is that requests send into such
a queue will never see a reply processed - the application
hangs.

  This commit has also been cc'd to upstream stable.

  == Fix ==
  104f708fd ("s390/zcrypt: reinit ap queue state machine during device probe")

  == Regression Potential ==
  Low.  Limited to s390.

  
  == Original Bug Description ==
  Description:  kernel: zcrypt: reinit ap queue state machine

  Symptom:  Zcrypt ap queue device not operational at host level after a
    kvm guest used it.

  Problem:  The vfio device driver when receiving an ap queue device does
    additional resets thereby removing the registration for
    interrupts for  the ap device done by the ap bus core
    code. So when later the vfio driver releases the device and
    one of the default zcrypt drivers takes care of the device
    the interrupt registration needs to get renewed. The current
    code does no renew and result is that requests send into such
    a queue will never see a reply processed - the application
    hangs.

  Solution: This patch adds a function which resets the aq queue state
    machine for the ap queue device and triggers the walk through
    the initial states (which are reset and registration for
    interrupts). This function is now called before the driver's
    probe function is invoked.
    When the association between driver and device is released,
    the driver's remove function is called. The current
    implementation calls a ap queue function
    ap_queue_remove(). This invokation has been moved to the ap
    bus function to make the probe / remove pair for ap bus and
    drivers more symmetric.

  Reproduction: Set up an kvm guest to use one or more ap queues in
    pass-through mode. Start the guest. Stop the guest. Reassign
    the ap resources back to the host system. Run an application
    which uses exactly this ap resources. Without the fix, the
    application hangs; with the fix the application should run
    fine.

  Upstream commit(s):
  104f708fd1241b22f808bdf066ab67dc5a051de5
  Available on kernel.org

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805414/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


  1   2   3   4   5   6   7   8   9   10   >