[Kernel-packages] [Bug 1829027] Re: [19.10 FEAT] Secure boot in kernel
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains c9896acc7851109d4e84c1e3a54cb1b9794dea6b Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 268a78404973594d1a7ec3a2b6a2474e0543a435 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 99feaa717e558cf4f2ad0faf53acac3cf9cc7438 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains e23a8020ce4e094e10d717d39a8ce799243bf8c1 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 653beba24d4cd281b078eab48c9bce956939061c Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 8e4964261374aaec9f4a83de076ceb11c8cdc044 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains d0d249d75dda1b101624316a52d117be07b8ccff Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains f6780686525cc69a16a893cac0dd6adfbf25b7ff Ubuntu-5.2.0-8.9 v5.2 Hence changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** 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/1829027 Title: [19.10 FEAT] Secure boot in kernel Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Secure Boot in support of NIAP OSPP v4.2 for Common Criteria Certification To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1829027/+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 1825353] Re: [19.10 FEAT] PCI directed interrupt support
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 6324b4de6d Ubuntu-5.2.0-8.9 v5.2 $ git show 6324b4de6d commit 6324b4de6dca40361399d3e9a2f2f1cbe8e7e11e Author: Sebastian Ott Date: Tue Feb 12 16:23:13 2019 +0100 s390/pci: mark command line parser data __initdata No point to keep that around. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Hence changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1825353 Title: [19.10 FEAT] PCI directed interrupt support Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Enhancement for PCI interrupt affinity. Provided with kernel >=5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1825353/+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 1825352] Re: [19.10 FEAT] Additional PCI MI/O instructions
** 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/1825352 Title: [19.10 FEAT] Additional PCI MI/O instructions Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Introduce additional instructions for PCI I/O avaiable with kernel >=5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1825352/+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 1829270] Re: [19.10 FEAT] Enhanced hardware diagnose data for the Linux kernel
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 4ad78b8651 Ubuntu-5.2.0-8.9 v5.2 $ git show 4ad78b8651commit 4ad78b8651aacf26b3ab6d1e784952eb70469c43 Author: Collin Walling Date: Thu Dec 6 17:30:04 2018 -0500 s390/setup: set control program code via diag 318 The s390x diagnose 318 instruction sets the control program name code (CPNC) and control program version code (CPVC) to provide useful information regarding the OS during debugging. The CPNC is explicitly set to 4 to indicate a Linux/KVM environment. The CPVC is a 7-byte value containing: - 3-byte Linux version code, currently set to 0 - 3-byte unique value, currently set to 0 - 1-byte trailing null Signed-off-by: Collin Walling Acked-by: Janosch Frank Acked-by: Heiko Carstens Reviewed-by: David Hildenbrand Reviewed-by: Cornelia Huck Message-Id: <1544135405-22385-2-git-send-email-wall...@linux.ibm.com> [set version code to 0 until the structure is fully defined] Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Hence changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1829270 Title: [19.10 FEAT] Enhanced hardware diagnose data for the Linux kernel Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Improved problem determination capabilities for KVM setups via enhanced handling of hardware diagnose data in the Linux kernel. Available with kernel 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1829270/+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 1830239] Re: [19.10 FEAT] zKVM: Add hardware CPU Model - kernel part
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 8ec2fa52eac5 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 4f45b90e1c03 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 173aec2d5a9f Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains d668139718a9 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 13209ad0395c Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains d5cb6ab1e3d4 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 7832e91cd33f Ubuntu-5.2.0-8.9 v5.2 Hence changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1830239 Title: [19.10 FEAT] zKVM: Add hardware CPU Model - kernel part Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Support of additional hardware instructions improving performance in KVM environments. Will be made available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830239/+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 1832626] Re: [19.10 FEAT] kernel address space layout randomization
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains cd479eccd2 Ubuntu-5.2.0-8.9 v5.2 $ git show cd479eccd2 commit cd479eccd2e057116d504852814402a1e68ead80 Author: Martin Schwidefsky Date: Mon Mar 4 12:33:28 2019 +0100 s390: limit brk randomization to 32MB For a 64-bit process the randomization of the program break is quite large with 1GB. That is as big as the randomization of the anonymous mapping base, for a test case started with '/lib/ld64.so.1 ' it can happen that the heap is placed after the stack. To avoid this limit the program break randomization to 32MB for 64-bit and keep 8MB for 31-bit. Reported-by: Stefan Liebler Signed-off-by: Martin Schwidefsky With that changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1832626 Title: [19.10 FEAT] kernel address space layout randomization Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: With kernel address space layout randomization (KASLR), the kernel can be loaded to a random location in memory. Protecting against certain attacks that rely on knowledge of the kernel addresses. Available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832626/+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 1834201] Re: [19.10 FEAT] Enhanced CPU-MF hardware counters - kernel part
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 46a984ffb8 Ubuntu-5.2.0-8.9 v5.2 $ git show 46a984ffb8 commit 46a984ffb86c8542fa510656fa8cb33befe8ee8f Author: Thomas Richter Date: Thu Mar 28 11:21:47 2019 +0100 s390/cpum_cf: Add support for CPU-MF SVN 6 Add support for the CPU-Measurement Facility counter second version number 6. This number is used to detect some more counters in the crypto counter set and the extended counter set. Signed-off-by: Thomas Richter Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky With that changing status to Fix Committed. ** Information type changed from Private to Public ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** 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/1834201 Title: [19.10 FEAT] Enhanced CPU-MF hardware counters - kernel part Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Enhance the CPU-MF hardware counters for improved HW support Enable customers and IBM service to monitor and analyze the performance using improved hardware counters. Will be provided with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1834201/+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 1835554] Re: [19.10 FEAT] Crypto AP DD: handle reconfiguration events
$ rmadison --arch=s390x linux-generic | grep eoan-proposed
linux-generic | 5.2.0.8.9 | eoan-proposed | s390x
$ git tag --contains 16222cfb96
Ubuntu-5.2.0-8.9
v5.2
$ git show 16222cfb96
commit 16222cfb96b02a4a3e38e52012f2a6304850c3c9
Author: Harald Freudenberger
Date: Wed Apr 3 13:18:22 2019 +0200
s390/zcrypt: fix possible deadlock situation on ap queue remove
With commit 01396a374c3d ("s390/zcrypt: revisit ap device remove
procedure") the ap queue remove is now a two stage process. However,
a del_timer_sync() call may trigger the timer function which may
try to lock the very same spinlock as is held by the function
just initiating the del_timer_sync() call. This could end up in
a deadlock situation. Very unlikely but possible as you need to
remove an ap queue at the exact sime time when a timeout of a
request occurs.
Signed-off-by: Harald Freudenberger
Reported-by: Pierre Morel
Fixes: commit 01396a374c3d ("s390/zcrypt: revisit ap device remove
procedure")
Signed-off-by: Martin Schwidefsky
With that changing status to Fix Committed.
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Committed
** Changed in: ubuntu-z-systems
Status: Incomplete => Fix Committed
** 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/1835554
Title:
[19.10 FEAT] Crypto AP DD: handle reconfiguration events
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in linux package in Ubuntu:
Fix Committed
Bug description:
Handle concurrent additions or removals of AP facilities.
Available with kernel 5.1
Git Commit: 16222cfb96
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1835554/+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 1835553] Re: [19.10 FEAT] kernel crypto: seed PRNG with TRNG
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 769f020b6c Ubuntu-5.2.0-8.9 v5.2 $ git show 769f020b6c commit 769f020b6c9283d61c59de3559375ec7e961a424 Author: Harald Freudenberger Date: Tue Apr 16 13:41:26 2019 +0200 s390/crypto: use TRNG for seeding/reseeding With the z14 machine there came also a CPACF hardware extension which provides a True Random Number Generator. This TRNG can be accessed with a new subfunction code within the CPACF prno instruction and provides random data with very high entropy. So if there is a TRNG available, let's use it for initial seeding and reseeding instead of the current implementation which tries to generate entropy based on stckf (store clock fast) jitters. For details about the amount of data needed and pulled for seeding and reseeding there can be explaining comments in the code found. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky With that changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: Incomplete => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1835553 Title: [19.10 FEAT] kernel crypto: seed PRNG with TRNG Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: On a Z14 or later system the PRNG (/dev/prandom) shall be seeded with the CPACF TRNG. In that case the default reseeding frequency shall be increased t make up for the additional cost of the TRNG instruction. In additionthe STCLKF based seeding shall use a smaller buffer. Will be provided with kernel 5.2 Git commit . 769f020b6c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1835553/+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 1830617] Re: [19.10 FEAT] Enhanced boot support for KVM guests - kernel part
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 5abb9351df Ubuntu-5.2.0-8.9 v5.2 $ git show 5abb9351df commit 5abb9351dfd937d43193f4d09af9c72bfe2c4180 Author: Vasily Gorbik Date: Mon Apr 1 19:11:03 2019 +0200 s390/uv: introduce guest side ultravisor code The Ultravisor Call Facility (stfle bit 158) defines an API to the Ultravisor (UV calls), a mini hypervisor located at machine level. With help of the Ultravisor, KVM will be able to run "protected" VMs, special VMs whose memory and management data are unavailable to KVM. The protected VMs can also request services from the Ultravisor. The guest api consists of UV calls to share and unshare memory with the kvm hypervisor. To enable this feature support PROTECTED_VIRTUALIZATION_GUEST kconfig option has been introduced. Co-developed-by: Janosch Frank Signed-off-by: Janosch Frank Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky With that changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1830617 Title: [19.10 FEAT] Enhanced boot support for KVM guests - kernel part Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Enhance the boot support from all applicable sources. Enhanced boot support for KVM setups, Will be made available with kernel 5.2 only To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830617/+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 1830742] Re: [19.10 FEAT] Enhanced Hardware Support
$ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains a8fd61688d Ubuntu-5.2.0-8.9 v5.2 $ git show a8fd61688d commit a8fd61688dfad6fdce95fa64cacd8a66595697b8 Author: Martin Schwidefsky Date: Tue Feb 5 16:15:01 2019 +0100 s390: report new CPU capabilities Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: "Vector-Enhancements Facility 2" (tag "vxe2", hwcap 2^15) "Vector-Packed-Decimal-Enhancement Facility" (tag "vxp", hwcap 2^16) "Enhanced-Sort Facility" (tag "sort", hwcap 2^17) "Deflate-Conversion Facility" (tag "dflt", hwcap 2^18) Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky With that changing status to Fix Committed. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Committed ** 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/1830742 Title: [19.10 FEAT] Enhanced Hardware Support Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Summary: kernel: report new CPU capabilities Description: Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: the "Vector-Enhancements Facility 2", the "Vector-Packed-Decimal-Enhancement Facility", the "Enhanced-Sort Facility" and the "Deflate-Conversion Facility" Upstream-ID: a8fd61688dfad6fdce95fa64cacd8a66595697b8 Available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830742/+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 1831899] Re: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space
Tricky combination of glibc/libc6 and kernel. Dumps are downloaded and bug assigned to 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/1831899 Title: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Status in linux source package in Bionic: New Bug description: == Comment: #0 - Robert J. Brenneman - 2019-05-30 11:16:45 == ---Problem Description--- Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in virtual kernel address space Contact Information = rjbr...@us.ibm.com ---uname output--- Linux ECOS0018 4.15.0-50-generic #54-Ubuntu SMP Tue May 7 05:57:08 UTC 2019 s390x s390x s390x GNU/Linux Machine Type = z13 2964 NE1 ---System Hang--- z/VM took a VMDUMP and reIPLed ---Debugger--- A debugger is not configured ---Steps to Reproduce--- boot system, start jenkins, let it run a couple days Stack trace output: 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138 05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0 05/29/19 13:24:06 (?<1201>? 0x1201) 05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48 05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8 Oops output: 05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in libc-2.23.so?3ffaca0+185000? 05/29/19 13:24:06 Failing address: TEID: 0800 05/29/19 13:24:06 Fault in primary space mode while using user ASCE. 05/29/19 13:24:06 AS:000710b241c7 R3:0024 05/29/19 13:24:06 Unable to handle kernel pointer dereference in virtual kernel address space 05/29/19 13:24:06 Failing address: 03dbe000 TEID: 03dbe403 05/29/19 13:24:06 Fault in home space mode while using kernel ASCE. 05/29/19 13:24:06 AS:00ea8007 R3:0024 05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP 05/29/19 13:24:06 Modules linked in: veth xt_nat xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_con 05/29/19 13:24:06 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 dasd_fba_mod dasd_eckd_mod sha1_s390 sha_common dasd_mod 05/29/19 13:24:06 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.15.0-50-generic #54-Ubuntu 05/29/19 13:24:06 Hardware name: IBM 2964 NE1 798 (z/VM 6.4.0) 05/29/19 13:24:06 Krnl PSW : dcb002be 72762961 (__tlb_remove_table+0x56/0xd0) 05/29/19 13:24:06 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 05/29/19 13:24:06 Krnl GPRS: ffba 02b8 02b80003 00eacac8 05/29/19 13:24:06 ffba 00b9 0700 000a 05/29/19 13:24:06 0404c001 0007d2fb5c38 0007cf71fdf0 03dbe000 05/29/19 13:24:06 03dbe018 008fe740 0007cf71fd08 0007cf71fcd8 05/29/19 13:24:06 Krnl Code: 0012b956: ec2c002a027f clij %r2,2,12,12b9aa 05/29/19 13:24:06 0012b95c: ec26001d037e cij %r2,3,6,12b996 05/29/19 13:24:06#0012b962: 41c0b018 la %r12,24(%r11) 05/29/19 13:24:06>0012b966: e548b008 mvghi 8(%r11),0 05/29/19 13:24:06 0012b96c: a7390008 lghi %r3,8 05/29/19 13:24:06 0012b970: b904002b lgr %r2,%r11 05/29/19 13:24:06 0012b974: c0e5000e8f8a brasl %r14,2fd888 05/29/19 13:24:06 0012b97a: a718 lhi %r1,-1 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 05/29/19 13:24:06 ?<008e87f0>? ext_int_h
[Kernel-packages] [Bug 1836340] Re: [19.10 FEAT] Export CPU-MF counter sets as auxtrace data for perf
Based on this information: $ rmadison --arch=s390x linux-generic | grep eoan-proposed linux-generic | 5.2.0.8.9 | eoan-proposed | s390x $ git tag --contains 8dabe9c43af7aa78b16ce0d61bc595eca20c7a70 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains fe5908bccc565f85cab025695627678cf257f91e Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains b6ffdf27f3d4f1e9af56effe6f86989170d71e95 Ubuntu-5.2.0-8.9 v5.2 $ git tag --contains 1c410fd6a561af452aba282b1cd3cabef2080d72 Ubuntu-5.2.0-8.9 v5.2 I'm setting the status of this ticket to Fix Committed. ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: New => Fix Committed ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Frank Heimes (frank-heimes) ** Changed in: linux (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => Frank Heimes (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/1836340 Title: [19.10 FEAT] Export CPU-MF counter sets as auxtrace data for perf Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Available with kernel 5.1 https://github.com/torvalds/linux/commit/fe5908bccc The feature has the following commit IDs commit 8dabe9c43af7aa78b16ce0d61bc595eca20c7a70 perf report: Dump s390 counter set data to file commit fe5908bccc565f85cab025695627678cf257f91e s390/cpum_cf_diag: Add support for s390 counter facility diagnostic trace commit b6ffdf27f3d4f1e9af56effe6f86989170d71e95 s390/cpumf: Fix warning from check_processor_id commit 1c410fd6a561af452aba282b1cd3cabef2080d72 s390/cpum_cf_diag: Add support for CPU-MF SVN 6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836340/+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 1836153] Re: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part
** 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/1836153 Title: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: Feature request to be applied to Ubuntu 18.04 - kernel. The git commit information is already provided within https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830239 Once this feature is accepted all information for integration will be provided by IBM kernel 5.2 down to 4.15. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836153/+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 1836153] Re: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part
** Description changed: + SRU Justification: + == + + [Impact] + + * New hardware is not supported by qemu and won't run run, due to + missing hardware CPU model + + [Fix] + + * 11ba5961a2156a4f210627ed8421387e2531b100 11ba596 "KVM: s390: add debug + logging for cpu model subfunctions" + + * 346fa2f891c71a9b98014f8f62c15f4c7dd95ec1 346fa2f "KVM: s390: implement + subfunction processor calls" + + * 7832e91cd33f21f3cf82b003478c292915a1ec14 7832e91 "KVM: s390: add + vector enhancements facility 2 to cpumodel" + + * d5cb6ab1e3d4d7e0648a167f6290e89f6e86964e d5cb6ab "KVM: s390: add + vector BCD enhancements facility to cpumodel" + + * 13209ad0395c4de7fa48108b1dac72e341d5c089 13209ad "KVM: s390: add MSA9 + to cpumodel" + + * d668139718a9e2260702777bd8d86d71c30b6539 d668139 "KVM: s390: provide + query function for instructions returning 32 byte" + + * 173aec2d5a9fa5f40e462661a8283fcafe04764f 173aec2 "KVM: s390: add + enhanced sort facilty to cpu model" + + * 4f45b90e1c03466202fca7f62eaf32243f220830 4f45b90 "KVM: s390: add + deflate conversion facilty to cpu model" + + * 8ec2fa52eac53bff7ef1cedbc4ad8af650ec937c 8ec2fa5 "KVM: s390: enable + MSA9 keywrapping functions depending on cpu model" + + [Test Case] + + * need to be tested by IBM on pre-rel. hardware or simulator + + [Regression Potential] + + * The regression potential can be considered as low since these changes + are limited to arch/s390 + + * changes are in support for new and upcoming hardware and shouldn't + affect existing s390x systems + + [Other Info] + + * the first 2 commits are the key ones, the other 7 are needed to make + them applly cleanly + + * these patches are already all included in upstream kernel 5.2, hence + they are in eoan's kernel 5.2 + + * qemu package SRU in LP 1836154 complements this SRU - for testing both + need to be in place + + * I could apply the commit IDs cleanly with 'cherry-picks --strategy=recursive -X theirs' and checked that no patches on top were pulled in + _ + Feature request to be applied to Ubuntu 18.04 - kernel. - The git commit information is already provided within + The git commit information is already provided within https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830239 Once this feature is accepted all information for integration will be provided by IBM kernel 5.2 down to 4.15. -- 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/1836153 Title: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: SRU Justification: == [Impact] * New hardware is not supported by qemu and won't run run, due to missing hardware CPU model [Fix] * 11ba5961a2156a4f210627ed8421387e2531b100 11ba596 "KVM: s390: add debug logging for cpu model subfunctions" * 346fa2f891c71a9b98014f8f62c15f4c7dd95ec1 346fa2f "KVM: s390: implement subfunction processor calls" * 7832e91cd33f21f3cf82b003478c292915a1ec14 7832e91 "KVM: s390: add vector enhancements facility 2 to cpumodel" * d5cb6ab1e3d4d7e0648a167f6290e89f6e86964e d5cb6ab "KVM: s390: add vector BCD enhancements facility to cpumodel" * 13209ad0395c4de7fa48108b1dac72e341d5c089 13209ad "KVM: s390: add MSA9 to cpumodel" * d668139718a9e2260702777bd8d86d71c30b6539 d668139 "KVM: s390: provide query function for instructions returning 32 byte" * 173aec2d5a9fa5f40e462661a8283fcafe04764f 173aec2 "KVM: s390: add enhanced sort facilty to cpu model" * 4f45b90e1c03466202fca7f62eaf32243f220830 4f45b90 "KVM: s390: add deflate conversion facilty to cpu model" * 8ec2fa52eac53bff7ef1cedbc4ad8af650ec937c 8ec2fa5 "KVM: s390: enable MSA9 keywrapping functions depending on cpu model" [Test Case] * need to be tested by IBM on pre-rel. hardware or simulator [Regression Potential] * The regression potential can be considered as low since these changes are limited to arch/s390 * changes are in support for new and upcoming hardware and shouldn't affect existing s390x systems [Other Info] * the first 2 commits are the key ones, the other 7 are needed to make them applly cleanly * these patches are already all included in upstream kernel 5.2, hence they are in eoan's kernel 5.2 * qemu package SRU in LP 1836154 complements this SRU - for testing both need to be in place * I could apply the commit IDs cleanly with 'cherry-picks --strategy=recursive -X theirs' and checked that no patches on top were pulled in _ Feature request to be applied to Ubuntu 18.04 - kernel. The git commit information is already provided within https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830239 Once this feature is accepted all information for integration will be provided by IBM ke
[Kernel-packages] [Bug 1836153] Re: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2019-July/thread.html#102228 ** Changed in: linux (Ubuntu) Status: New => In Progress ** 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/1836153 Title: [18.04 FEAT] zKVM: Add hardware CPU Model - kernel part Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: SRU Justification: == [Impact] * New hardware is not supported by qemu and won't run run, due to missing hardware CPU model [Fix] * 11ba5961a2156a4f210627ed8421387e2531b100 11ba596 "KVM: s390: add debug logging for cpu model subfunctions" * 346fa2f891c71a9b98014f8f62c15f4c7dd95ec1 346fa2f "KVM: s390: implement subfunction processor calls" * 7832e91cd33f21f3cf82b003478c292915a1ec14 7832e91 "KVM: s390: add vector enhancements facility 2 to cpumodel" * d5cb6ab1e3d4d7e0648a167f6290e89f6e86964e d5cb6ab "KVM: s390: add vector BCD enhancements facility to cpumodel" * 13209ad0395c4de7fa48108b1dac72e341d5c089 13209ad "KVM: s390: add MSA9 to cpumodel" * d668139718a9e2260702777bd8d86d71c30b6539 d668139 "KVM: s390: provide query function for instructions returning 32 byte" * 173aec2d5a9fa5f40e462661a8283fcafe04764f 173aec2 "KVM: s390: add enhanced sort facilty to cpu model" * 4f45b90e1c03466202fca7f62eaf32243f220830 4f45b90 "KVM: s390: add deflate conversion facilty to cpu model" * 8ec2fa52eac53bff7ef1cedbc4ad8af650ec937c 8ec2fa5 "KVM: s390: enable MSA9 keywrapping functions depending on cpu model" [Test Case] * need to be tested by IBM on pre-rel. hardware or simulator [Regression Potential] * The regression potential can be considered as low since these changes are limited to arch/s390 * changes are in support for new and upcoming hardware and shouldn't affect existing s390x systems [Other Info] * the first 2 commits are the key ones, the other 7 are needed to make them applly cleanly * these patches are already all included in upstream kernel 5.2, hence they are in eoan's kernel 5.2 * qemu package SRU in LP 1836154 complements this SRU - for testing both need to be in place * I could apply the commit IDs cleanly with 'cherry-picks --strategy=recursive -X theirs' and checked that no patches on top were pulled in _ Feature request to be applied to Ubuntu 18.04 - kernel. The git commit information is already provided within https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830239 Once this feature is accepted all information for integration will be provided by IBM kernel 5.2 down to 4.15. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836153/+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 1829270] Re: [19.10 FEAT] Enhanced hardware diagnose data for the Linux kernel
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1829270 Title: [19.10 FEAT] Enhanced hardware diagnose data for the Linux kernel Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Improved problem determination capabilities for KVM setups via enhanced handling of hardware diagnose data in the Linux kernel. Available with kernel 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1829270/+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 1830239] Re: [19.10 FEAT] zKVM: Add hardware CPU Model - kernel part
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1830239 Title: [19.10 FEAT] zKVM: Add hardware CPU Model - kernel part Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Support of additional hardware instructions improving performance in KVM environments. Will be made available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830239/+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 1830617] Re: [19.10 FEAT] Enhanced boot support for KVM guests - kernel part
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1830617 Title: [19.10 FEAT] Enhanced boot support for KVM guests - kernel part Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Enhance the boot support from all applicable sources. Enhanced boot support for KVM setups, Will be made available with kernel 5.2 only To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830617/+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 1830742] Re: [19.10 FEAT] Enhanced Hardware Support
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1830742 Title: [19.10 FEAT] Enhanced Hardware Support Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Summary: kernel: report new CPU capabilities Description: Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: the "Vector-Enhancements Facility 2", the "Vector-Packed-Decimal-Enhancement Facility", the "Enhanced-Sort Facility" and the "Deflate-Conversion Facility" Upstream-ID: a8fd61688dfad6fdce95fa64cacd8a66595697b8 Available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830742/+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 1825353] Re: [19.10 FEAT] PCI directed interrupt support
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1825353 Title: [19.10 FEAT] PCI directed interrupt support Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Enhancement for PCI interrupt affinity. Provided with kernel >=5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1825353/+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 1829027] Re: [19.10 FEAT] Secure boot in kernel
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1829027 Title: [19.10 FEAT] Secure boot in kernel Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Secure Boot in support of NIAP OSPP v4.2 for Common Criteria Certification To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1829027/+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 1825352] Re: [19.10 FEAT] Additional PCI MI/O instructions
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1825352 Title: [19.10 FEAT] Additional PCI MI/O instructions Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Introduce additional instructions for PCI I/O avaiable with kernel >=5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1825352/+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 1835553] Re: [19.10 FEAT] kernel crypto: seed PRNG with TRNG
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1835553 Title: [19.10 FEAT] kernel crypto: seed PRNG with TRNG Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: On a Z14 or later system the PRNG (/dev/prandom) shall be seeded with the CPACF TRNG. In that case the default reseeding frequency shall be increased t make up for the additional cost of the TRNG instruction. In additionthe STCLKF based seeding shall use a smaller buffer. Will be provided with kernel 5.2 Git commit . 769f020b6c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1835553/+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 1832626] Re: [19.10 FEAT] kernel address space layout randomization
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1832626 Title: [19.10 FEAT] kernel address space layout randomization Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: With kernel address space layout randomization (KASLR), the kernel can be loaded to a random location in memory. Protecting against certain attacks that rely on knowledge of the kernel addresses. Available with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832626/+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 1835554] Re: [19.10 FEAT] Crypto AP DD: handle reconfiguration events
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1835554 Title: [19.10 FEAT] Crypto AP DD: handle reconfiguration events Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Handle concurrent additions or removals of AP facilities. Available with kernel 5.1 Git Commit: 16222cfb96 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1835554/+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 1834201] Re: [19.10 FEAT] Enhanced CPU-MF hardware counters - kernel part
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1834201 Title: [19.10 FEAT] Enhanced CPU-MF hardware counters - kernel part Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Enhance the CPU-MF hardware counters for improved HW support Enable customers and IBM service to monitor and analyze the performance using improved hardware counters. Will be provided with kernel 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1834201/+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 1836340] Re: [19.10 FEAT] Export CPU-MF counter sets as auxtrace data for perf
Since kernel 5.2 eventually landed in eoan's release pocket: linux-generic | 5.2.0.8.9 | eoan| s390 I'm changing this LP ticket 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/1836340 Title: [19.10 FEAT] Export CPU-MF counter sets as auxtrace data for perf Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Available with kernel 5.1 https://github.com/torvalds/linux/commit/fe5908bccc The feature has the following commit IDs commit 8dabe9c43af7aa78b16ce0d61bc595eca20c7a70 perf report: Dump s390 counter set data to file commit fe5908bccc565f85cab025695627678cf257f91e s390/cpum_cf_diag: Add support for s390 counter facility diagnostic trace commit b6ffdf27f3d4f1e9af56effe6f86989170d71e95 s390/cpumf: Fix warning from check_processor_id commit 1c410fd6a561af452aba282b1cd3cabef2080d72 s390/cpum_cf_diag: Add support for CPU-MF SVN 6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836340/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
I can also confirm that the issue still exists, but only if I run perf top as root or with sudo. Running perf top it as regular user is fine - even w/o the patches packages! -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
Sorry, I missed comment #31, just saw now #32. Please have a look here on how to install the build env. and the kernel sources: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel Just notice that the deb line in the sources.list file is different for non-x86 (like s390x) It must be: deb-src http://us.ports.ubuntu.com/ubuntu-ports/ bionic main deb-src http://us.ports.ubuntu.com/ubuntu-ports/ bionic-updates main instead of: deb-src http://archive.ubuntu.com/ubuntu bionic main deb-src http://archive.ubuntu.com/ubuntu bionic-updates main -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
And afterwards you can get the package that contains perf like this: $ dpkg -S $(which perf) linux-tools-common: /usr/bin/perf $ apt-get source linux-tools-common For the linux-tools source package that fits to your running kernel, do: apt-get source linux-tools-$(uname -r) -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
'apt-get source' should work - just double checked it here: # just these two deb-src lines should be sufficient: $ grep ^deb-src /etc/apt/sources.list deb-src http://us.ports.ubuntu.com/ubuntu-ports/ bionic main deb-src http://us.ports.ubuntu.com/ubuntu-ports/ bionic-updates main $ apt-get source linux-image-$(uname -r) Reading package lists... Done Picking 'linux' as source package instead of 'linux-image-4.15.0-54-generic' NOTICE: 'linux' packaging is maintained in the 'Git' version control system at: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic Please use: git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic to retrieve the latest (possibly unreleased) updates to the package. Skipping already downloaded file 'linux_4.15.0-54.58.dsc' Skipping already downloaded file 'linux_4.15.0.orig.tar.gz' Skipping already downloaded file 'linux_4.15.0-54.58.diff.gz' Need to get 0 B of source archives. Skipping unpack of already unpacked source in linux-4.15.0 $ Did you do the required "apt update" after modifying the sources.list file - to update the local archive package index? But 'klebers' will share the sources he used ... -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
Hi Thomas, thanks for looking into this and doing this analysis. Sounds reasonable to bring it upstream first and do a backport afterwards. Since 18.10/cosmic with kernel 4.18 is EOL in between, we just need to get it into bionic 4.15 and disco 5.0 - but I assume you've meant that anyway ... ** Changed in: ubuntu-z-systems Status: Confirmed => 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1827755] Re: nx842 - CRB request time out (-110) when uninstall NX modules and initiate NX request
** Changed in: ubuntu-power-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/1827755 Title: nx842 - CRB request time out (-110) when uninstall NX modules and initiate NX request 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: [Impact] PowerPC 842 hardware compression support is currently broken, this effects workloads like zswap and others that exploit 842 hardware compression on Power. [Test] - Install nx-compress and nx-842-powernv modules - Initiate NX request - Uninstall these modules - Initiate NX request again and we get CRB timeout with error -110 Test kernel available in the PPA, please see comment #4 and please see comment #5 that verifies the PPA kernel works as expected. [Fix] IBM has identified that the following upstream patch fixes the issue: 656ecc16e8fc crypto/nx: Initialize 842 high and normal RxFIFO control registers [Regression Potential] The patch only impacts the nx-842 modules, only available on PowerPC architecture and does not have any impact on other architectures or generic code. Risk of regression is very low. [Other Info] ---Problem Description--- Normally nx-compress and nx-842-powernv modules are loaded when selects 842-nx compressor if not loaded and execute forever during system execution. So we will not see this bug in normal case. But we are seeing NX CRB request timeout when uninstall these modules and load them or select 842-nx compressor. ---uname output--- 18.04 Machine Type = P9 system ---Steps to Reproduce--- - Install nx-compress and nx-842-powernv modules - Initiate NX request - Uninstall these modules - Initiate NX request again and we get CRB timeout with error -110 Patches are included in 4.19-rc1 6e708000ec2c93c2bde6a46aa2d6c3e80d4eaeb9 - powerpc/powernv: Export opal_check_token symbol 656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca5 - crypto/nx: Initialize 842 high and normal RxFIFO control registers > Looks like the first commit was included in a recent 18.04 update > (4.15.0-48.51), see > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819989 > > but I don't see the second one there yet. > > If this is still needed, I would suggest getting this bug mirrored to LP to > put on Canonical's radar. We need second commit (656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca) to fix this actual issue. But no use of having the first commit without second one. The first one just exports opal_check_token symbol which is used in the second commit. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1827755/+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 1832625] Re: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different
Chaning "linux (Ubuntu)" to Fix Released, since the patch got upstream accepted with kernel 5.1 and in between kernel 5.2 landed in Eoan's release pocket. ** Changed in: linux (Ubuntu) Status: In Progress => 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/1832625 Title: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different 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 Released Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: SRU Justification: == [Impact] * 'zkey validate' shows wrong information about master key registers * this might lead to unsuccessful usage of pkeys, although the master key and the derived keys are correct [Fix] * ebb7c695d3bc7a4986b92edc8d9ef43491be183e ebb7c69 "pkey: Indicate old mkvp only if old and current mkvp are different" [Test Case] * set a CCA master key * generate a pkey * 'change' (or better set) the current CCA master key to the exact same master key again which is currently in use * execute a 'zkey validate' [Regression Potential] * The regression potential can be considered as very low since this is purely s390x specific * changes are limited to a single file (drivers/s390/crypto/pkey_api.c) * patch changes only one line (actually expands an if stmt) * and all this happens only in a very specific situation (in case a new master key was set, using the same key as before) [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' __ Description: pkey: Indicate old mkvp only if old and curr. mkvp are different Symptom: zkey validate shows wrong information about master key registers Problem: When the CCA master key is set twice with the same master key, then the old and the current master key are the same and thus the verification patterns are the same, too. The check to report if a secure key is currently wrapped by the old master key erroneously reports old mkvp in this case. Solution: Fix this by checking current and old mkvp and report OLD only if current and old mkvp are different. Reproduction: Change the CCA master key but set the exact same master key that is already used. Then do a 'zkey validate' command on a secure key Component: kernel 5.1 rc1 Upstream-ID: ebb7c695d3bc7a4986b92edc8d9ef43491be183e This fix will be provided with kernel >=5.1 , will be integrate in 19.10 by default. But should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832625/+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 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Changing "linux (Ubuntu)" to Fix Released, since the patch got upstream accepted with kernel 5.2 and kernel 5.2 landed in Eoan's release pocket. ** Changed in: linux (Ubuntu) Status: In Progress => 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/1832624 Title: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs 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 Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification: == [Impact] * Unable to maintain control-only crypto domains * The communication to control-only domains does not work in any way. * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. [Fix] * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390 -zcrypt-Fix-wrong-dispatching-for-control-domain.patch [Test Case] * Configure a control-only domain to the activation profile of LPAR A * Configure a control-and-usage domain to the activation profile of LPAR B * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) [Regression Potential] * The regression potential can be considered as moderate since this is purely s390x specific * and again limited to CryptoExpress adapter cards. * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. * It applies cleanly to disco master-next while cherry-picking, but needs the the backport (from comment #3) for bionic's master-next kernel 4.15. * Once target kernel 5.2 has landed in Eoan, it will be in Eoan, too. __ Description: kernel: Fix wrong dispatching for control domain CPRBs Symptom: Unable to maintain control-only crypto domains Problem: LPARs may have control-only crypto domains assigned. Such a domain can be controlled (for example master keys can be set) but can't be used for regualar crypto load (usage). A crypto domain may be assigned for control-and-usage to only one active LPAR. But the very same domain may be assigned for control-only to one or more other LPARs. However, trying to communicate in any way with a control-only crypto domain did not work. So a simple query for the state of the master keys on a control-only domain failed and the TKE does not even show this domain. Even worse, when the lowest domain (in a numerically sense) is a control-only domain, the TKE does not even see the crypto cards at all. Solution: This fix introduces some code which checks if an CCA CPRB is addressing a control-only domain. If that's the case and there is a default control-and-usage domain available the CPRB is send to this other domain instead. The target domain field within the CPRB is untouched and the crypto card firmware code detects this working-as-designed mismatch and does the right job and addresses the control domain. Reproduction: 1. Add a control-only domain to the crypto configuration of an LPAR and re-activate the LPAR. 2. Connect the TKE the LPAR and try to visit the master key verification patterns of this control-only domain. 3. Will fail without the fix, will succeed with the fix. Component: kernel Upstream-ID: 7379e652797c0b9b5f6caea1576f2dff9ce6a708 This fix is requested for 19.10 but should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+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 1832623] Re: [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing
Changing "linux (Ubuntu)" to Fix Released, since the patch got upstream accepted with kernel 5.2 and kernel 5.2 landed in Eoan's release pocket. ** Changed in: linux (Ubuntu) Status: In Progress => 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/1832623 Title: [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing 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 Released Status in linux source package in Cosmic: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: SRU Justification: == [Impact] * Wrong encryption/decryption with gcm-aes-s390 on z14. * gcm-aes-s390 does not process scatter-gather input and output lists correctly if list entries of sizes being not multiples of the blocksize (16 bytes) are used, which results in wrong calculations. [Fix] * bef9f0ba300a55d79a69aa172156072182176515 bef9f0b "s390/crypto: fix gcm-aes-s390 selftest failures" [Test Case] * z14 with kernel >= 5.1 needed * If disabled, enable the crypto self tests. * Monitor syslog during modprobe of the aes_s390 kernel module. As this module usually gets automatically inserted during system startup you may need to unload the aes_s390 kernel module before re-inserting it. * Without the fix a message like "kernel: alg: aead: gcm-aes-s390 encryption test failed (wrong result) on test vector 1,..." will show up. * With the fix, all selftests will pass and nothing is reported in syslog. [Regression Potential] * The regression potential can be considered as low since this is purely s390x specific * affects one mode of the hardware crypto facility CPACF * and happens only on z14 (since z14 is the only model that currently supports the gcm-aes-s390 mode). * Applications using aes-gcm via the AF_ALG interface are not affected since this API ensures scatter/gather list entries with chunk sizes in multiples of 16 bytes. * Changes are limited to a single s390x crypto file /arch/s390/crypto/aes_s390.c [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * Since this affects z14 only, final test need to be done by IBM. * Applied cleanly for me on bionic master-next. __ Description: kernel: Fix gcm-aes-s390 wrong scatter-gather list processing Symptom: gcm-aes-s390 wrong en/decryption processing Problem: The current gcm aes s390 implementation does not process scatter-gather input and output lists correct when list entries with sizes not multiples of the blocksize of 16 bytes are used. Result may be wrong calculated encrypted or decrypted data. This can only happen on z14 (this is the only machine which supports aes-gcm in hardware via CPACF). Please note that applications using aes-gcm via the AF_ALG interface are not affected as this API ensures scatter/gather list entries with chunk sizes in multiples of 16 bytes. However, all exploiters of aes-gcm within the kernel may be affected. Solution: Rework of the scatter/gather walk within the aes_s390 kernel module implementation with the goal to support any list entry size. Reproduction: With kernel 5.1 there has been an improvement on the crypto selftests. There are now tests run with fragmented scatter/gather lists. So: 1. You need at least a z14 and kernel >= 5.1. 2. If disabled, enable the crypto self tests. 3. Watch for syslog entries during modprobe of the aes_s390 kernel module. As this module usually gets automatically inserted during system startup you may need to unload the aes_s390 kernel module before re-inserting it. 4. Without the fix something like "kernel: alg: aead: gcm-aes-s390 encryption test failed (wrong result) on test vector 1,..." will show up. With the fix, all selftests will pass and nothing is reported in syslog. Component: kernel Upstream-ID: bef9f0ba300a55d79a69aa172156072182176515 This request is targeted for 19.10, but should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832623/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help
[Kernel-packages] [Bug 1829972] Re: Require improved hypervisor detection patch in Ubuntu 18.04
Changing "linux (Ubuntu)" to Fix Released, since the patch got upstream accepted with kernel 5.0 and in between kernel 5.2 landed in Eoan's release pocket. Hence the entire ticket is 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/1829972 Title: Require improved hypervisor detection patch in Ubuntu 18.04 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: == Justification == The s390x early machine detection code check will set all the uknown hypervisors to z/VM, this will cause crash for any non KVM, z/VM system. == Fixes == 03aa047e (s390/early: improve machine detection) Patch can be cherry-picked into Bionic kernel. Instead of setting all the other hypervisors to z/VM, it will only set MACHINE_FLAG_VM if it matches the case. == Tests == A test kernel could be found here: https://people.canonical.com/~phlin/kernel/lp-1829972-s390x-early/ Boot tested on a s390x KVM node and verified by IBM as well. == Regression Potential == Low, this just improves the detection logic and the changes are specific to s390x. == Original Bug Report == This kernel commit is requested to be included into the bionic's 4.15.0 LTS kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=03aa047ef2db4985e444af6ee1c1dd084ad9fb4c s390/early: improve machine detection Right now the early machine detection code check stsi 3.2.2 for "KVM" and set MACHINE_IS_VM if this is different. As the console detection uses diagnose 8 if MACHINE_IS_VM returns true this will crash Linux early for any non z/VM system that sets a different value than KVM. So instead of assuming z/VM, do not set any of MACHINE_IS_LPAR, MACHINE_IS_VM, or MACHINE_IS_KVM. This is required for a dedicated SSC exploiter To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1829972/+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 1836857] Re: [18.04 FEAT] Enhanced hardware support
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2019-July/thread.html#102485 ** Information type changed from Private to Public ** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: ubuntu-z-systems Status: Incomplete => 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/1836857 Title: [18.04 FEAT] Enhanced hardware support Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: SRU Justification: == [Impact] * Enhanced hardware support for upcoming machine and make sure it can report new CPU capabilities [Fix] * a8fd61688dfad6fdce95fa64cacd8a66595697b8 a8fd616 "s390: report new CPU capabilities" * 142c52d7bce45d335f48d53fdbf428bb15cf3924 142c52d "s390: add alignment hints to vector load and store" [Test Case] * check /proc/cpuinfo in bionic running on upcoming machine - currently only IBM can do that [Regression Potential] * The regression potential can be considered as very low since these changes are limited to arch/s390 * and mainly adds code for the capability to report new features in cpuinfo - in case of running on new hardware [Other Info] * a8fd616 got upstream accepted with 5.2; 142c52d with 5.1 - hence both are already in eoan __ Feature request to apply this to Ubuntu 18.04 in support of new machine. Summary: kernel: report new CPU capabilities Description: Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: the "Vector-Enhancements Facility 2", the "Vector-Packed-Decimal-Enhancement Facility", the "Enhanced-Sort Facility" and the "Deflate-Conversion Facility" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836857/+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 1837073] Re: linux 5.2.0-8.9 disabled backlight on s390x.
** Tags added: s390x -- 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/1837073 Title: linux 5.2.0-8.9 disabled backlight on s390x. Status in ddcci-driver-linux package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Looks like ddcci-driver-linux started to fail on s390x with the switch from kernel 5.0.0-21-generic to 5.2.0-8-generic http://autopkgtest.ubuntu.com/packages/d/ddcci-driver-linux/eoan/s390x According to changelog and diff: - [Config] CONFIG_BACKLIGHT_CLASS_DEVICE=n on s390x from Seth Forshee. According to the build log of ddci backlight rm: cannot remove '.tmp_versions/ddcci-backlight.mod': No such file or directory Makefile:227: = WARNING Makefile:228: 'SUBDIRS' will be removed after Linux 5.3 Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead Makefile:230: == Makefile:227: = WARNING Makefile:228: 'SUBDIRS' will be removed after Linux 5.3 Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead Makefile:230: == ERROR: "devm_backlight_device_register" [/var/lib/dkms/ddcci/0.3.2/build/ddcci-backlight/ddcci-backlight.ko] undefined! make[3]: *** [scripts/Makefile.modpost:91: __modpost] Error 1 make[2]: *** [Makefile:1628: modules] Error 2 make[1]: *** [Makefile:37: ddcci-backlight.ko] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ddcci-driver-linux/+bug/1837073/+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 1832625] Re: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different
Changing the cosmic entry to Invalid since it reached it's EOL on July, 18th 2019 (last week). With that change the entire ticket is now Fix Released. ** Changed in: linux (Ubuntu Cosmic) Status: Fix Committed => Invalid ** 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/1832625 Title: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different 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: Invalid Status in linux source package in Disco: Fix Released Bug description: SRU Justification: == [Impact] * 'zkey validate' shows wrong information about master key registers * this might lead to unsuccessful usage of pkeys, although the master key and the derived keys are correct [Fix] * ebb7c695d3bc7a4986b92edc8d9ef43491be183e ebb7c69 "pkey: Indicate old mkvp only if old and current mkvp are different" [Test Case] * set a CCA master key * generate a pkey * 'change' (or better set) the current CCA master key to the exact same master key again which is currently in use * execute a 'zkey validate' [Regression Potential] * The regression potential can be considered as very low since this is purely s390x specific * changes are limited to a single file (drivers/s390/crypto/pkey_api.c) * patch changes only one line (actually expands an if stmt) * and all this happens only in a very specific situation (in case a new master key was set, using the same key as before) [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' __ Description: pkey: Indicate old mkvp only if old and curr. mkvp are different Symptom: zkey validate shows wrong information about master key registers Problem: When the CCA master key is set twice with the same master key, then the old and the current master key are the same and thus the verification patterns are the same, too. The check to report if a secure key is currently wrapped by the old master key erroneously reports old mkvp in this case. Solution: Fix this by checking current and old mkvp and report OLD only if current and old mkvp are different. Reproduction: Change the CCA master key but set the exact same master key that is already used. Then do a 'zkey validate' command on a secure key Component: kernel 5.1 rc1 Upstream-ID: ebb7c695d3bc7a4986b92edc8d9ef43491be183e This fix will be provided with kernel >=5.1 , will be integrate in 19.10 by default. But should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832625/+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 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** 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/1832624 Title: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs 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 Disco: Fix Released Bug description: SRU Justification: == [Impact] * Unable to maintain control-only crypto domains * The communication to control-only domains does not work in any way. * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. [Fix] * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390 -zcrypt-Fix-wrong-dispatching-for-control-domain.patch [Test Case] * Configure a control-only domain to the activation profile of LPAR A * Configure a control-and-usage domain to the activation profile of LPAR B * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) [Regression Potential] * The regression potential can be considered as moderate since this is purely s390x specific * and again limited to CryptoExpress adapter cards. * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. * It applies cleanly to disco master-next while cherry-picking, but needs the the backport (from comment #3) for bionic's master-next kernel 4.15. * Once target kernel 5.2 has landed in Eoan, it will be in Eoan, too. __ Description: kernel: Fix wrong dispatching for control domain CPRBs Symptom: Unable to maintain control-only crypto domains Problem: LPARs may have control-only crypto domains assigned. Such a domain can be controlled (for example master keys can be set) but can't be used for regualar crypto load (usage). A crypto domain may be assigned for control-and-usage to only one active LPAR. But the very same domain may be assigned for control-only to one or more other LPARs. However, trying to communicate in any way with a control-only crypto domain did not work. So a simple query for the state of the master keys on a control-only domain failed and the TKE does not even show this domain. Even worse, when the lowest domain (in a numerically sense) is a control-only domain, the TKE does not even see the crypto cards at all. Solution: This fix introduces some code which checks if an CCA CPRB is addressing a control-only domain. If that's the case and there is a default control-and-usage domain available the CPRB is send to this other domain instead. The target domain field within the CPRB is untouched and the crypto card firmware code detects this working-as-designed mismatch and does the right job and addresses the control domain. Reproduction: 1. Add a control-only domain to the crypto configuration of an LPAR and re-activate the LPAR. 2. Connect the TKE the LPAR and try to visit the master key verification patterns of this control-only domain. 3. Will fail without the fix, will succeed with the fix. Component: kernel Upstream-ID: 7379e652797c0b9b5f6caea1576f2dff9ce6a708 This fix is requested for 19.10 but should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+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 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
** Changed in: ubuntu-power-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/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Artful: Won't Fix Status in linux source package in Bionic: Fix Released Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: Fix Released Bug description: [Impact] File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods. [Test case] $ sudo perf record -k 1 -e instructions:u ./java -agentpath:/usr/lib/linux-tools-5.0.0-8/libperf-jvmti.so crc32 $ sudo perf inject -i ./perf.data -j -o ./perf.data.jitted $ sudo perf report -f -i ./perf.data.jitted [Fix] Include java build dependencies and install the library into linux-tools package. [Regression potential] Small regression potential, an extra file is distributed and is not automatically linked to anything. It could impact the build, which was tested. ---Problem Description--- File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods ---uname output--- linux-image-4.13.0-36-generic Machine Type = not relevant ---Debugger--- A debugger is not configured ---Steps to Reproduce--- File libperf-jvmti.so is missing in linux-tools-common deb provided for Ubuntu 17.10 making it impossible to use perf for the JVM JITed methods. I also checked if the file is available on launchpad (https://launchpad.net/ubuntu/+source/linux) for Bionic Beaver proposed (main) at it's also absent there: gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-common_4.15.0-13.14_all.deb | fgrep jvm gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-4.15.0-13-generic_4.15.0-13.14_ppc64el.deb | fgrep jvm I do see the file in tools/perf/jvmti dir in the source .tar.gz, but apparently it's no being packaged in any .deb file? Thanks. Userspace tool common name: perf The userspace tool has the following bit modes: 64-bit Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+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 1832623] Re: [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing
Changing the cosmic entry to Invalid since it reached it's EOL on July, 18th 2019 (last week). With that change the entire ticket is now Fix Released. ** Changed in: linux (Ubuntu Cosmic) Status: Fix Committed => Invalid ** 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/1832623 Title: [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list 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: Invalid Status in linux source package in Disco: Fix Released Bug description: SRU Justification: == [Impact] * Wrong encryption/decryption with gcm-aes-s390 on z14. * gcm-aes-s390 does not process scatter-gather input and output lists correctly if list entries of sizes being not multiples of the blocksize (16 bytes) are used, which results in wrong calculations. [Fix] * bef9f0ba300a55d79a69aa172156072182176515 bef9f0b "s390/crypto: fix gcm-aes-s390 selftest failures" [Test Case] * z14 with kernel >= 5.1 needed * If disabled, enable the crypto self tests. * Monitor syslog during modprobe of the aes_s390 kernel module. As this module usually gets automatically inserted during system startup you may need to unload the aes_s390 kernel module before re-inserting it. * Without the fix a message like "kernel: alg: aead: gcm-aes-s390 encryption test failed (wrong result) on test vector 1,..." will show up. * With the fix, all selftests will pass and nothing is reported in syslog. [Regression Potential] * The regression potential can be considered as low since this is purely s390x specific * affects one mode of the hardware crypto facility CPACF * and happens only on z14 (since z14 is the only model that currently supports the gcm-aes-s390 mode). * Applications using aes-gcm via the AF_ALG interface are not affected since this API ensures scatter/gather list entries with chunk sizes in multiples of 16 bytes. * Changes are limited to a single s390x crypto file /arch/s390/crypto/aes_s390.c [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * Since this affects z14 only, final test need to be done by IBM. * Applied cleanly for me on bionic master-next. __ Description: kernel: Fix gcm-aes-s390 wrong scatter-gather list processing Symptom: gcm-aes-s390 wrong en/decryption processing Problem: The current gcm aes s390 implementation does not process scatter-gather input and output lists correct when list entries with sizes not multiples of the blocksize of 16 bytes are used. Result may be wrong calculated encrypted or decrypted data. This can only happen on z14 (this is the only machine which supports aes-gcm in hardware via CPACF). Please note that applications using aes-gcm via the AF_ALG interface are not affected as this API ensures scatter/gather list entries with chunk sizes in multiples of 16 bytes. However, all exploiters of aes-gcm within the kernel may be affected. Solution: Rework of the scatter/gather walk within the aes_s390 kernel module implementation with the goal to support any list entry size. Reproduction: With kernel 5.1 there has been an improvement on the crypto selftests. There are now tests run with fragmented scatter/gather lists. So: 1. You need at least a z14 and kernel >= 5.1. 2. If disabled, enable the crypto self tests. 3. Watch for syslog entries during modprobe of the aes_s390 kernel module. As this module usually gets automatically inserted during system startup you may need to unload the aes_s390 kernel module before re-inserting it. 4. Without the fix something like "kernel: alg: aead: gcm-aes-s390 encryption test failed (wrong result) on test vector 1,..." will show up. With the fix, all selftests will pass and nothing is reported in syslog. Component: kernel Upstream-ID: bef9f0ba300a55d79a69aa172156072182176515 This request is targeted for 19.10, but should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832623/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@list
[Kernel-packages] [Bug 1837522] Re: GCC Miscompilation of vector shift
** Package changed: linux (Ubuntu) => gcc-8 (Ubuntu)
** 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) => 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/1837522
Title:
GCC Miscompilation of vector shift
Status in Ubuntu on IBM z Systems:
Triaged
Status in gcc-8 package in Ubuntu:
New
Bug description:
Vector shift miscompilation
---Steps to Reproduce---
t.c:
__vector int
foo (__vector int a, int s)
{
return a << (s + 3);
}
gcc -O3 -march=z13 t.c -S -mzvector
foo:
veslf %v24,%v24,0(%r2) < +3 is omitted
br %r14
Contact Information = andreas.kreb...@de.ibm.com
Userspace tool common name: GCC
The userspace tool has the following bit modes: 64
Backported fix has been applied to GCC 8 branch as r273493:
https://gcc.gnu.org/viewcvs?rev=273493&root=gcc&view=rev
S/390: Fix vector shift count operand
We currently use subst definitions to handle the different variants of shift
count operands. Unfortunately, in the vector shift pattern the shift count
operand is used directly. Without it being adjusted for the 'subst' variants
the
displacement value is omitted resulting in a wrong shift count being applied.
This patch needs to be applied to older branches as well.
gcc/ChangeLog:
2019-07-15 Andreas Krebbel
Backport from mainline
2019-07-01 Andreas Krebbel
* config/s390/vector.md: Fix shift count operand printing.
gcc/testsuite/ChangeLog:
2019-07-15 Andreas Krebbel
Backport from mainline
2019-07-01 Andreas Krebbel
* gcc.target/s390/vector/vec-shift-2.c: New test.
Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/s390/vector/vec-shift-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/s390/vector.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1837522/+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 1828035] Re: StrongSwan with GCM and large packet sizes produces unstable behavior
The 'gcm-aes-s390' patch landed today in bionic's release pocket. The work was done based on the kernel SRU of LP 1832623, which is now Fix Released. Hence I mark this ticket as Fix Released as well. ** 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/1828035 Title: StrongSwan with GCM and large packet sizes produces unstable behavior Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in strongswan package in Ubuntu: Incomplete Bug description: StrongSwan with GCM and large packet sizes produces unstable behavior when used in Linux native environment. ---uname output--- Linux ubu01 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:29:11 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = 3906 / M04 (z14), LPAR (dedicated) ---Debugger--- A debugger is not configured ---Steps to Reproduce--- On two separate machines (Linux native), install StrongSwan and on both machines, configure the encryption with aes128gcm8 for IPsec. Then run the following command from one of the machine: ``` $# ping -s 1024 ``` Small packet sizes are working as expected. However, anything large (around 1024 bytes or more) are sometimes returning wrong values, or the packets are getting lost. This problem does not occur for ciphers not involving GCM. Userspace tool common name: StrongSwan The userspace tool has the following bit modes: both Userspace package: StrongSwan Userspace tool obtained from project website: na -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828035/+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 1831899] Re: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space
** Description changed: == Comment: #0 - Robert J. Brenneman - 2019-05-30 11:16:45 == ---Problem Description--- Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in virtual kernel address space - - Contact Information = rjbr...@us.ibm.com - + + Contact Information = rjbr...@us.ibm.com + ---uname output--- Linux ECOS0018 4.15.0-50-generic #54-Ubuntu SMP Tue May 7 05:57:08 UTC 2019 s390x s390x s390x GNU/Linux - - Machine Type = z13 2964 NE1 - + + Machine Type = z13 2964 NE1 + ---System Hang--- - z/VM took a VMDUMP and reIPLed - + z/VM took a VMDUMP and reIPLed + (the attached and available dumps are Linux dumps) + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - boot system, start jenkins, let it run a couple days - + boot system, start jenkins, let it run a couple days + Stack trace output: - 05/29/19 13:24:06 Call Trace: + 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) - 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 - 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 - 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 - 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 - 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 - 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138 - 05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0 + 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 + 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 + 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 + 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 + 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 + 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138 + 05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0 05/29/19 13:24:06 (?<1201>? 0x1201) - 05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48 - 05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8 + 05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48 + 05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8 - Oops output: - 05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in libc-2.23.so?3ffaca0+185000? + 05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in libc-2.23.so?3ffaca0+185000? 05/29/19 13:24:06 Failing address: TEID: 0800 05/29/19 13:24:06 Fault in primary space mode while using user ASCE. - 05/29/19 13:24:06 AS:000710b241c7 R3:0024 + 05/29/19 13:24:06 AS:000710b241c7 R3:0024 05/29/19 13:24:06 Unable to handle kernel pointer dereference in virtual kernel address space 05/29/19 13:24:06 Failing address: 03dbe000 TEID: 03dbe403 05/29/19 13:24:06 Fault in home space mode while using kernel ASCE. - 05/29/19 13:24:06 AS:00ea8007 R3:0024 - 05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP + 05/29/19 13:24:06 AS:00ea8007 R3:0024 + 05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP 05/29/19 13:24:06 Modules linked in: veth xt_nat xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_con 05/29/19 13:24:06 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 dasd_fba_mod dasd_eckd_mod sha1_s390 sha_common dasd_mod 05/29/19 13:24:06 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.15.0-50-generic #54-Ubuntu 05/29/19 13:24:06 Hardware name: IBM 2964 NE1 798 (z/VM 6.4.0) 05/29/19 13:24:06 Krnl PSW : dcb002be 72762961 (__tlb_remove_table+0x56/0xd0) 05/29/19 13:24:06 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 05/29/19 13:24:06 Krnl GPRS: ffba 02b8 02b80003 00eacac8 05/29/19 13:24:06 ffba 00b9 0700 000a 05/29/19 13:24:06 0404c001 0007d2fb5c38 0007cf71fdf0 03dbe000 05/29/19 13:24:06 03dbe018 008fe740 0007cf71fd08 0007cf71fcd8 05/29/19 13:24:06 Krnl Code: 0012b956: ec2c002a027f clij %r2,2,12,12b9aa 05/29/19 13:24:06 0012b95c: ec26001d037e cij %r2,3,6,12b996 05/29/19 13:24:06#0012b962: 41c0b018 la %r12,24(%r11) 05/29/19 13:24:06>0012b966: e548b008 mvghi 8(%r11),0 05/29/19 13:24:06 0012b96c: a7390008 lghi %r3,8 05/29/19 13:24:06 0012b970: b904002b lgr %r2,%r11 05/29/19 13:24:06
[Kernel-packages] [Bug 1804149] Re: Kernel panic, Oops: 0004 ilc:3 [#1] SMP, iscsi_q_20 iscsi_xmitworker [libiscsi]
** 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 1822870] Re: Backport support for software count cache flush Spectre v2 mitigation. (CVE) (required for POWER9 DD2.3)
** 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 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process
@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 1741860] Re: Use the kernel default for crashkernel offset
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
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 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part
** 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
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 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures
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 1818854] Re: [Ubuntu] vfio-ap: add subsystem to matrix device to avoid libudev failures
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 1788432] Re: 4.15 s390x kernel BUG at /build/linux-Gycr4Z/linux-4.15.0/drivers/block/virtio_blk.c:565!
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 03ff800058da
[Kernel-packages] [Bug 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part
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 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command
** 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 1788098] Re: Avoid migration issues with aligned 2MB THB
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&id=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 1824101] Re: [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr
** 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 1824101] Re: [Ubuntu] RDMA/smc: Replace ib_query_gid with rdma_get_gid_attr
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 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process
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 1820275] Re: btrfs-kernel oops from btrfs subvolume delete command
** 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 1819989] Re: Add basic support to NVLink2 passthrough
** 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 1814892] Re: [19.04 FEAT] qeth: Enhanced link speed - kernel part
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 1741904] Re: [18.04 FEAT] dm-crypt with protected keys - s390 tools part
** 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 1799472] Re: [19.04 FEAT] Enable graphical distro installer to run natively with virtio-gpu
** 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 1805793] Re: [19.04 FEAT] qeth: Full-blown TCP Segmentation Offload
** 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 1811354] Re: [19.04 FEAT] in-kernel crypto: support protected keys generated by random in paes module
** 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 1814899] Re: [19.04 FEAT] qeth: Performance Improvements
** 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 1831899] Re: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space
Thx for the additional data.
However, I can confirm juergh that there is an issue with both dumps:
I downloaded them again from Box, but vmconvert is still not able to handle
them:
$ ls -l
total 5735304
-rw-rw-r-- 1 ubuntu ubuntu 2737907971 Aug 14 08:23 dump.190529.1324
-rw-rw-r-- 1 ubuntu ubuntu 3135030835 Aug 14 09:19 dump.190529.2120
$ vmconvert ./dump.190529.1324
vmconvert: Input file './dump.190529.1324' is not a vmdump
$ vmconvert ./dump.190529.2120
vmconvert: Input file './dump.190529.2120' is not a vmdump
$
Please can you try to vmconvert them on YOUR system?
And in case it works let us know which tool/version you used? ('vmconvert -v',
'apt-cache policy s390-tools', 'lsb_release -a' and 'uname -a')
Thx
--
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/1831899
Title:
Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in
kernel virtual address space
Status in Ubuntu on IBM z Systems:
Triaged
Status in linux package in Ubuntu:
New
Status in linux source package in Bionic:
New
Bug description:
== Comment: #0 - Robert J. Brenneman - 2019-05-30
11:16:45 ==
---Problem Description---
Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in virtual
kernel address space
Contact Information = rjbr...@us.ibm.com
---uname output---
Linux ECOS0018 4.15.0-50-generic #54-Ubuntu SMP Tue May 7 05:57:08 UTC 2019
s390x s390x s390x GNU/Linux
Machine Type = z13 2964 NE1
---System Hang---
z/VM took a VMDUMP and reIPLed
(the attached and available dumps are Linux dumps)
---Debugger---
A debugger is not configured
---Steps to Reproduce---
boot system, start jenkins, let it run a couple days
Stack trace output:
05/29/19 13:24:06 Call Trace:
05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0)
05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70
05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570
05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358
05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0
05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8
05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138
05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0
05/29/19 13:24:06 (?<1201>? 0x1201)
05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48
05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8
Oops output:
05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in
libc-2.23.so?3ffaca0+185000?
05/29/19 13:24:06 Failing address: TEID: 0800
05/29/19 13:24:06 Fault in primary space mode while using user ASCE.
05/29/19 13:24:06 AS:000710b241c7 R3:0024
05/29/19 13:24:06 Unable to handle kernel pointer dereference in virtual
kernel address space
05/29/19 13:24:06 Failing address: 03dbe000 TEID: 03dbe403
05/29/19 13:24:06 Fault in home space mode while using kernel ASCE.
05/29/19 13:24:06 AS:00ea8007 R3:0024
05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP
05/29/19 13:24:06 Modules linked in: veth xt_nat xt_tcpudp ipt_MASQUERADE
nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
iptable_filter xt_con
05/29/19 13:24:06 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390
sha256_s390 dasd_fba_mod dasd_eckd_mod sha1_s390 sha_common dasd_mod
05/29/19 13:24:06 CPU: 7 PID: 0 Comm: swapper/7 Not tainted
4.15.0-50-generic #54-Ubuntu
05/29/19 13:24:06 Hardware name: IBM 2964 NE1 798 (z/VM 6.4.0)
05/29/19 13:24:06 Krnl PSW : dcb002be 72762961
(__tlb_remove_table+0x56/0xd0)
05/29/19 13:24:06 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1
PM:0 RI:0 EA:3
05/29/19 13:24:06 Krnl GPRS: ffba 02b8
02b80003 00eacac8
05/29/19 13:24:06 ffba 00b9
0700 000a
05/29/19 13:24:06 0404c001 0007d2fb5c38
0007cf71fdf0 03dbe000
05/29/19 13:24:06 03dbe018 008fe740
0007cf71fd08 0007cf71fcd8
05/29/19 13:24:06 Krnl Code: 0012b956: ec2c002a027f clij
%r2,2,12,12b9aa
05/29/19 13:24:06 0012b95c: ec26001d037e cij
%r2,3,6,12b996
05/29/19 13:24:06#0012b962: 41c0b018 la
%r12,24(%r11)
05/29/19 13:24:06>0012b966: e548b008 mvghi
8(%r11),0
05/29/19 13:24:06 0012b96c: a7390008 lghi
%r3,8
05/29/19 13:24:06 0012b970: b904002b lgr
%r2,%r11
05/29/19 13:24:06 000
[Kernel-packages] [Bug 1831899] Re: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space
Hi Robert, yes I can access this file and have it already downloaded. It was just not clear to me that these are the same or similar dumps , so that the other (huge) files are not really needed... The tgz seems to be fine, since it's extractable w/o issues: $ tar xvfz 4_kdumps.tgz 201905311552/ 201905311552/dump.201905311552 201905311552/dmesg.201905311552 201906030926/ 201906030926/dmesg.201906030926 201906030926/dump.201906030926 201906041107/ 201906041107/dmesg.201906041107 201906041107/dump.201906041107 201906061158/ 201906061158/dmesg.201906061158 201906061158/dump.201906061158 kexec_cmd linux-image-4.15.0-50-generic-201905311552.crash linux-image-4.15.0-50-generic-201906030926.crash linux-image-4.15.0-50-generic-201906041107.crash -- 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/1831899 Title: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Status in linux source package in Bionic: New Bug description: == Comment: #0 - Robert J. Brenneman - 2019-05-30 11:16:45 == ---Problem Description--- Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in virtual kernel address space Contact Information = rjbr...@us.ibm.com ---uname output--- Linux ECOS0018 4.15.0-50-generic #54-Ubuntu SMP Tue May 7 05:57:08 UTC 2019 s390x s390x s390x GNU/Linux Machine Type = z13 2964 NE1 ---System Hang--- z/VM took a VMDUMP and reIPLed (the attached and available dumps are Linux dumps) ---Debugger--- A debugger is not configured ---Steps to Reproduce--- boot system, start jenkins, let it run a couple days Stack trace output: 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138 05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0 05/29/19 13:24:06 (?<1201>? 0x1201) 05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48 05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8 Oops output: 05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in libc-2.23.so?3ffaca0+185000? 05/29/19 13:24:06 Failing address: TEID: 0800 05/29/19 13:24:06 Fault in primary space mode while using user ASCE. 05/29/19 13:24:06 AS:000710b241c7 R3:0024 05/29/19 13:24:06 Unable to handle kernel pointer dereference in virtual kernel address space 05/29/19 13:24:06 Failing address: 03dbe000 TEID: 03dbe403 05/29/19 13:24:06 Fault in home space mode while using kernel ASCE. 05/29/19 13:24:06 AS:00ea8007 R3:0024 05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP 05/29/19 13:24:06 Modules linked in: veth xt_nat xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_con 05/29/19 13:24:06 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 dasd_fba_mod dasd_eckd_mod sha1_s390 sha_common dasd_mod 05/29/19 13:24:06 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.15.0-50-generic #54-Ubuntu 05/29/19 13:24:06 Hardware name: IBM 2964 NE1 798 (z/VM 6.4.0) 05/29/19 13:24:06 Krnl PSW : dcb002be 72762961 (__tlb_remove_table+0x56/0xd0) 05/29/19 13:24:06 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 05/29/19 13:24:06 Krnl GPRS: ffba 02b8 02b80003 00eacac8 05/29/19 13:24:06 ffba 00b9 0700 000a 05/29/19 13:24:06 0404c001 0007d2fb5c38 0007cf71fdf0 03dbe000 05/29/19 13:24:06 03dbe018 008fe740 0007cf71fd08 0007cf71fcd8 05/29/19 13:24:06 Krnl Code: 0012b956: ec2c002a027f clij %r2,2,12,12b9aa 05/29/19 13:24:06 0012b95c: ec26001d037e cij %r2,3,6,12b996 05/29/19 13:24:06#0012b962: 41c0b018 la %r12,24(%r11) 05/29/19 13:24:06>0012b966: e548b008 mvghi 8(%r11),0 05/29/19 13:24:06 0012b96c: a7390008 lghi %r3,8 05/29/19 13:24:06 0012b970: b904002b lgr %r2,%r11 05/29/19 13:24
[Kernel-packages] [Bug 1836860] Re: [18.04 FEAT] Enhanced CPU-MF hardware counters - kernel part
** Tags removed: verification-needed-disco ** Tags added: verification-done-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/1836860 Title: [18.04 FEAT] Enhanced CPU-MF hardware counters - 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 Disco: Fix Committed Bug description: SRU Justification: == [Impact] * Enhanced CPU-MF hardware counters - fix lack of support of new hardware [Fix] * 46a984ffb86c8542fa510656fa8cb33befe8ee8f 46a984ff "s390/cpum_cf: Add support for CPU-MF SVN 6" * 820bace734722715c643dcb5f74b502cb912d4eb 820bace "s390/cpumf: Add extended counter set definitions for model 8561 and 8562" [Test Case] * try CPU-Measurement Facility counter on z14 and next generation hardware - only IBM can do that now [Regression Potential] * The regression potential can be considered as low since these changes are limited to arch/s390 * do only touch perf_* code * and mainly add code (rather than modify or remove) [Other Info] * first commit is taken from 5.2, second from 5.3-rc1 __ Enhance the CPU-MF hardware counters for improved HW support . Kernel 5.2 commits and kernel 5.3 patch on top Already requested for Ubuntu 19.10 kernel 5.2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834201 kernel 5.3 fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836739 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836860/+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 1836857] Re: [18.04 FEAT] Enhanced hardware support
** Tags removed: verification-needed-disco ** Tags added: verification-done-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/1836857 Title: [18.04 FEAT] Enhanced hardware support 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 Disco: Fix Committed Bug description: SRU Justification: == [Impact] * Enhanced hardware support for upcoming machine and make sure it can report new CPU capabilities [Fix] * a8fd61688dfad6fdce95fa64cacd8a66595697b8 a8fd616 "s390: report new CPU capabilities" * 142c52d7bce45d335f48d53fdbf428bb15cf3924 142c52d "s390: add alignment hints to vector load and store" [Test Case] * check /proc/cpuinfo in bionic running on upcoming machine - currently only IBM can do that [Regression Potential] * The regression potential can be considered as very low since these changes are limited to arch/s390 * and mainly adds code for the capability to report new features in cpuinfo - in case of running on new hardware [Other Info] * a8fd616 got upstream accepted with 5.2; 142c52d with 5.1 - hence both are already in eoan __ Feature request to apply this to Ubuntu 18.04 in support of new machine. Summary: kernel: report new CPU capabilities Description: Add hardware capability bits and features tags to /proc/cpuinfo for 4 new CPU features: the "Vector-Enhancements Facility 2", the "Vector-Packed-Decimal-Enhancement Facility", the "Enhanced-Sort Facility" and the "Deflate-Conversion Facility" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1836857/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
** 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: In Progress Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * b9c0a64901d5bdec6eafd38d1dc8fa0e2974fccb b9c0a64 "perf annotate: Fix s390 gap between kernel end and module start" * 12a6d2940b5f02b4b9f71ce098e3bb02bc24a9ea 12a6d29 "perf record: Fix module size on s390" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as medium since this happens only while using the perf top tool * and just 3 files are changed, and one of them is arch/s390/util/machine.c * but symbol and machine header in /tools/perf/util modified and several loc added [Other Info] * cherry-pick was possible to bionic-master-next and to disco-master- next (but used '--strategy=recursive -X theirs' for disco) * adding the patches to disco is to avoid regressions _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1831899] Re: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space
** 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/1831899 Title: Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in kernel virtual address space Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: New Status in linux source package in Bionic: New Bug description: == Comment: #0 - Robert J. Brenneman - 2019-05-30 11:16:45 == ---Problem Description--- Kernel Oops 3b in libc-2.23 unable to handle pointer dereference in virtual kernel address space Contact Information = rjbr...@us.ibm.com ---uname output--- Linux ECOS0018 4.15.0-50-generic #54-Ubuntu SMP Tue May 7 05:57:08 UTC 2019 s390x s390x s390x GNU/Linux Machine Type = z13 2964 NE1 ---System Hang--- z/VM took a VMDUMP and reIPLed (the attached and available dumps are Linux dumps) ---Debugger--- A debugger is not configured ---Steps to Reproduce--- boot system, start jenkins, let it run a couple days Stack trace output: 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x138 05/29/19 13:24:06 ?<00102cee>? enabled_wait+0x4e/0xe0 05/29/19 13:24:06 (?<1201>? 0x1201) 05/29/19 13:24:06 ?<0010303a>? arch_cpu_idle+0x32/0x48 05/29/19 13:24:06 ?<001c5ae8>? do_idle+0xe8/0x1a8 Oops output: 05/29/19 13:24:06 User process fault: interruption code 003b ilc:3 in libc-2.23.so?3ffaca0+185000? 05/29/19 13:24:06 Failing address: TEID: 0800 05/29/19 13:24:06 Fault in primary space mode while using user ASCE. 05/29/19 13:24:06 AS:000710b241c7 R3:0024 05/29/19 13:24:06 Unable to handle kernel pointer dereference in virtual kernel address space 05/29/19 13:24:06 Failing address: 03dbe000 TEID: 03dbe403 05/29/19 13:24:06 Fault in home space mode while using kernel ASCE. 05/29/19 13:24:06 AS:00ea8007 R3:0024 05/29/19 13:24:06 Oops: 003b ilc:3 ?#1? SMP 05/29/19 13:24:06 Modules linked in: veth xt_nat xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter xt_con 05/29/19 13:24:06 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 dasd_fba_mod dasd_eckd_mod sha1_s390 sha_common dasd_mod 05/29/19 13:24:06 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.15.0-50-generic #54-Ubuntu 05/29/19 13:24:06 Hardware name: IBM 2964 NE1 798 (z/VM 6.4.0) 05/29/19 13:24:06 Krnl PSW : dcb002be 72762961 (__tlb_remove_table+0x56/0xd0) 05/29/19 13:24:06 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 05/29/19 13:24:06 Krnl GPRS: ffba 02b8 02b80003 00eacac8 05/29/19 13:24:06 ffba 00b9 0700 000a 05/29/19 13:24:06 0404c001 0007d2fb5c38 0007cf71fdf0 03dbe000 05/29/19 13:24:06 03dbe018 008fe740 0007cf71fd08 0007cf71fcd8 05/29/19 13:24:06 Krnl Code: 0012b956: ec2c002a027f clij %r2,2,12,12b9aa 05/29/19 13:24:06 0012b95c: ec26001d037e cij %r2,3,6,12b996 05/29/19 13:24:06#0012b962: 41c0b018 la %r12,24(%r11) 05/29/19 13:24:06>0012b966: e548b008 mvghi 8(%r11),0 05/29/19 13:24:06 0012b96c: a7390008 lghi %r3,8 05/29/19 13:24:06 0012b970: b904002b lgr %r2,%r11 05/29/19 13:24:06 0012b974: c0e5000e8f8a brasl %r14,2fd888 05/29/19 13:24:06 0012b97a: a718 lhi %r1,-1 05/29/19 13:24:06 Call Trace: 05/29/19 13:24:06 (?<0012b97a>? __tlb_remove_table+0x6a/0xd0) 05/29/19 13:24:06 ?<0012ba34>? tlb_remove_table_rcu+0x54/0x70 05/29/19 13:24:06 ?<001f43b4>? rcu_process_callbacks+0x1d4/0x570 05/29/19 13:24:06 ?<008e92d4>? __do_softirq+0x124/0x358 05/29/19 13:24:06 ?<00179d52>? irq_exit+0xba/0xd0 05/29/19 13:24:06 ?<0010c412>? do_IRQ+0x8a/0xb8 05/29/19 13:24:06 ?<008e87f0>? ext_int_handler+0x134/0x13
[Kernel-packages] [Bug 1840026] Re: Ubuntu 18.04.2: Unable to boot guest with scsi disk having sgio flag
** Changed in: ubuntu-power-systems
Status: New => Opinion
--
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/1840026
Title:
Ubuntu 18.04.2: Unable to boot guest with scsi disk having sgio flag
Status in The Ubuntu-power-systems project:
Opinion
Status in libvirt package in Ubuntu:
Won't Fix
Status in linux package in Ubuntu:
New
Bug description:
== Comment: #0 - SRIKANTH AITHAL - 2019-07-03
22:28:43 ==
---Problem Description---
When we try to boot KVM guest with scsi disk having `sgio="unfiltered"`,
guest fails to boot throwing below error
virsh start vm1 --console
error: Failed to start domain vm1
error: Requested operation is not valid: unpriv_sgio is not supported by this
kernel
Contact Information = srikanth/bssrika...@in.ibm.com
---uname output---
Linux pkvmhab008 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:54:50 UTC
2019 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = witherspoon
---Debugger---
A debugger is not configured
---Steps to Reproduce---
Recreation steps:
1. Using scsi_debug driver to simulate scsi disk
#/sbin/modprobe scsi_debug dev_size_mb=2048 lbpu=1
#lsscsi|grep scsi_debug|awk '{print $6}'
/dev/sdk
2. Using below disk xml,
3. Try booting KVM guest with above disk,
# virsh start vm1 --console
error: Failed to start domain vm1
error: Requested operation is not valid: unpriv_sgio is not supported by this
kernel
Stack trace output:
no
Oops output:
no
System Dump Location:
There was no dump
*Additional Instructions for srikanth/bssrika...@in.ibm.com:
-Attach sysctl -a output output to the bug.
== Comment: #1 - SRIKANTH AITHAL - 2019-07-03
22:30:28 ==
== Comment: #2 - SRIKANTH AITHAL - 2019-07-03
22:31:03 ==
== Comment: #3 - SRIKANTH AITHAL - 2019-07-03
22:32:34 ==
unpriv_sgio is required for KVM guest running as qemu user to be able to
configure to issue any SCSI commands to storages.
== Comment: #5 - Fabiano Almeida Rosas - 2019-07-25
12:46:15 ==
It seems libvirt added support to `unpriv_sgio` but the kernel side of the
feature never got merged. It was then reverted on libvirt's side but the revert
caused issues so they re-enabled the support. As far as I can tell it will
always fail.
Some iterations of the kernel side feature:
https://lwn.net/Articles/533901/
https://lwn.net/Articles/535075/
https://lkml.org/lkml/2013/5/23/294
Libvirt side:
https://www.redhat.com/archives/libvir-list/2013-January/msg00013.html
Revert of the feature:
https://libvirt.org/git/?p=libvirt.git;a=patch;h=ce346623c19f82f4b35f3466e2ee4066847b750c
Unrevert:
https://www.redhat.com/archives/libvir-list/2015-June/msg00814.html
@Srikanth
Is this known to have worked at some point? Because it might be the case that
the distro is carrying these patches downstream. If that is the case I would
like to know which distro + version, so we can compare the setups.
== Comment: #6 - SRIKANTH AITHAL - 2019-07-25
22:35:33 ==
(In reply to comment #5)
> It seems libvirt added support to `unpriv_sgio` but the kernel side of the
> feature never got merged. It was then reverted on libvirt's side but the
> revert caused issues so they re-enabled the support. As far as I can tell it
> will always fail.
>
> Some iterations of the kernel side feature:
> https://lwn.net/Articles/533901/
> https://lwn.net/Articles/535075/
> https://lkml.org/lkml/2013/5/23/294
>
> Libvirt side:
> https://www.redhat.com/archives/libvir-list/2013-January/msg00013.html
>
> Revert of the feature:
> https://libvirt.org/git/?p=libvirt.git;a=patch;
> h=ce346623c19f82f4b35f3466e2ee4066847b750c
>
> Unrevert:
> https://www.redhat.com/archives/libvir-list/2015-June/msg00814.html
>
>
> @Srikanth
> Is this known to have worked at some point? Because it might be the case
> that the distro is carrying these patches downstream. If that is the case I
> would like to know which distro + version, so we can compare the setups.
No, this was uncovered as part of adding new testcases to our existing
test bucket. So we have not executed this testcase before.
== Comment: #8 - Daniel Henrique Barboza - 2019-08-07
15:32:47 ==
The error message "unpriv_sgio is not supported by this kernel" comes from a
Libvirt code that verifies if the file 'unpriv_sgio' exists in the sysfs path
of the device. In case it doesn't, this error message is thrown.
Fabiano is right in comment #5: the feature that implemented
unpriv_sgio didn't make it upstream. However, I found out that the
RHEL 7.4 manual [1] talks about the feature. With that in mind, I went
to a RHEL 7.6 server and verified that the feature exists in its 3.10
kernel by finding references of 'QUEUE_FLAG_UNPRIV_SG
[Kernel-packages] [Bug 1832625] Re: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different
** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- 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/1832625 Title: [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different 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: Invalid Status in linux source package in Disco: Fix Released Bug description: SRU Justification: == [Impact] * 'zkey validate' shows wrong information about master key registers * this might lead to unsuccessful usage of pkeys, although the master key and the derived keys are correct [Fix] * ebb7c695d3bc7a4986b92edc8d9ef43491be183e ebb7c69 "pkey: Indicate old mkvp only if old and current mkvp are different" [Test Case] * set a CCA master key * generate a pkey * 'change' (or better set) the current CCA master key to the exact same master key again which is currently in use * execute a 'zkey validate' [Regression Potential] * The regression potential can be considered as very low since this is purely s390x specific * changes are limited to a single file (drivers/s390/crypto/pkey_api.c) * patch changes only one line (actually expands an if stmt) * and all this happens only in a very specific situation (in case a new master key was set, using the same key as before) [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' __ Description: pkey: Indicate old mkvp only if old and curr. mkvp are different Symptom: zkey validate shows wrong information about master key registers Problem: When the CCA master key is set twice with the same master key, then the old and the current master key are the same and thus the verification patterns are the same, too. The check to report if a secure key is currently wrapped by the old master key erroneously reports old mkvp in this case. Solution: Fix this by checking current and old mkvp and report OLD only if current and old mkvp are different. Reproduction: Change the CCA master key but set the exact same master key that is already used. Then do a 'zkey validate' command on a secure key Component: kernel 5.1 rc1 Upstream-ID: ebb7c695d3bc7a4986b92edc8d9ef43491be183e This fix will be provided with kernel >=5.1 , will be integrate in 19.10 by default. But should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832625/+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 1841488] Re: [Ubuntu18.10][Backport] Crypto VMX Fixes
As alreday mentioned in comment #4 18.10/cosmic reached it's EOL and one
needs to migrate to disco:
So I just checked the situation on 19.04/disco.
In the current disco master two patches are in and two are out (as of today):
$ git log --oneline | grep -m 1 "Add support for VMS instructions by ASM"
5c380d6 crypto: vmx - Add support for VMS instructions by ASM
$ git log --oneline | grep -m 1 "fix copy-paste error in CTR mode"
6cef65e crypto: vmx - fix copy-paste error in CTR mode
$ git log --oneline | grep -m 1 "always increment IV as quadword"
$
$ git log --oneline | grep -m 1 "do nosimd fallback manually"
$
However disco master-next includes all patches (probably via a stable upstream
release update):
$ git log --oneline | grep -m 1 "Add support for VMS instructions by ASM"
5c380d6 crypto: vmx - Add support for VMS instructions by ASM
$ git log --oneline | grep -m 1 "fix copy-paste error in CTR mode"
6cef65e crypto: vmx - fix copy-paste error in CTR mode
$ git log --oneline | grep -m 1 "always increment IV as quadword"
b5df7b3 crypto: vmx - CTR: always increment IV as quadword
$ git log --oneline | grep -m 1 "do nosimd fallback manually"
c438f2b crypto: vmx - ghash: do nosimd fallback manually
Hence I suggest to wait for the next and upcoming disco/19.10 kernel and
close this LP once it got rolled out to the main pocket.
--
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/1841488
Title:
[Ubuntu18.10][Backport] Crypto VMX Fixes
Status in The Ubuntu-power-systems project:
Incomplete
Status in linux package in Ubuntu:
Incomplete
Bug description:
Cosmic is missing the fix for "5c380d623ed3 - crypto: vmx - Add
support for VMS instructions by ASM (4 years, 5 months ago) " ... which is fixed by 'crypto: vmx - fix copy-paste error
in CTR mode', it fixes a couple of incorrect branch targets, and usage
of an incorrect vector assembly instruction.
The others two patches ("crypto: vmx - CTR: always increment IV as
quadword ", "crypto: vmx - ghash: do nosimd fallback manually ") fixes
for ghash replaces the fallback mechanism that is used on powerpc an
operation is required to operate in interrupt context.
These fixes are important to avoid a potential data integrity issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841488/+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 1841447] Re: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384"
** Changed in: ubuntu-z-systems Status: New => 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/1841447 Title: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384" Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: New Bug description: A message "BUG: non-zero pgtables_bytes on freeing mm: -16384" occurs frequently during IPL of Ubuntu 18.04.1 and 18.04.2 and also periodically appear very often on the console device after the IPL has finished, which is very annoying. See the output of the dmesg and journalctl -b commands are attached. Both versions 18.04.1 and 18.04.2 use the same kernel: root@m83lp37:~# uname -a Linux m83lp37 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:03 UTC 2019 s390x s390x s390x GNU/Linux root@m83lp37:~# The problem appears on LPAR as well as on a z/VM guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841447/+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 1841447] Re: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384"
This seems to be a duplicate of LP 1840046 -- 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/1841447 Title: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384" Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: New Bug description: A message "BUG: non-zero pgtables_bytes on freeing mm: -16384" occurs frequently during IPL of Ubuntu 18.04.1 and 18.04.2 and also periodically appear very often on the console device after the IPL has finished, which is very annoying. See the output of the dmesg and journalctl -b commands are attached. Both versions 18.04.1 and 18.04.2 use the same kernel: root@m83lp37:~# uname -a Linux m83lp37 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:03 UTC 2019 s390x s390x s390x GNU/Linux root@m83lp37:~# The problem appears on LPAR as well as on a z/VM guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841447/+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 1841447] Re: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384"
LP 1840046 is just another report of the same issue, but the issue is likely to be fixed with upstream stable patchset 2019-07-23: that is currently already in progress: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837664 Yes, we can leave this open (of course) until LP 1837664 is completed (it's already Fix Committed). And after a quick verification if the issue is really solved, we can eventually close this LP. ** Changed in: linux (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-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/1841447 Title: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384" Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: A message "BUG: non-zero pgtables_bytes on freeing mm: -16384" occurs frequently during IPL of Ubuntu 18.04.1 and 18.04.2 and also periodically appear very often on the console device after the IPL has finished, which is very annoying. See the output of the dmesg and journalctl -b commands are attached. Both versions 18.04.1 and 18.04.2 use the same kernel: root@m83lp37:~# uname -a Linux m83lp37 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:03 UTC 2019 s390x s390x s390x GNU/Linux root@m83lp37:~# The problem appears on LPAR as well as on a z/VM guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841447/+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 1828596] Re: kdump fails when crash is triggered after DLPAR cpu add operation
** Changed in: ubuntu-power-systems Status: Triaged => 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/1828596 Title: kdump fails when crash is triggered after DLPAR cpu add operation Status in The Ubuntu-power-systems project: In Progress Status in kexec-tools package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Fix Released Status in kexec-tools source package in Xenial: New Status in makedumpfile source package in Xenial: New Status in kexec-tools source package in Bionic: New Status in makedumpfile source package in Bionic: Fix Committed Status in kexec-tools source package in Cosmic: New Status in makedumpfile source package in Cosmic: Won't Fix Status in kexec-tools source package in Disco: New Status in makedumpfile source package in Disco: Fix Committed Status in kexec-tools source package in Eoan: Invalid Status in makedumpfile source package in Eoan: Fix Released Bug description: [Impact] After a CPU add/hotplug operation on Power systems, kdump will fail after a crash. The kdump kernel needs to be reloaded after a CPU add/hotplug. [Test case] Do CPU add/hotplug, trigger a crash, and check for a successful kdump. [Regression potential] Multiple reloads caused by multiple sequential CPU adds may cause spurious log results, and systemd may fail to properly reload the kdump kernel. This has been handled by resetting the failure counter when doing such reloads. == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 == ---Problem Description--- kdump fails when crash is triggered after CPU add operation. Machine Type = na ---System Hang--- Crashed in early boot process of kdump kernel after crash Had to issue system reset from HMC to reclaim ---Steps to Reproduce--- 1. Configure kdump. 2. Add cpu from HMC. 3. Trigger crash. 4. Machine hangs after crash as below: --- [169250.213166] IPI complete [169250.234331] kexec: Starting switchover sequence. I'm in purgatory --- STRUCK HERE --- ---uname output--- na ---Debugger--- A debugger is not configured == Comment: #1 - Hari Krishna Bathini - 2019-05-10 05:56:46 == The problem is, kexec udev rule to restart kdump-tools service - when a core is added, is not being triggered. The old DT created by kexec (before the core is added) is being used by KDump Kernel. So, when system crashes on a thread from the added core(s), KDump kernel is failing to get the 'boot_cpuid' and eventually failing to boot.. == Comment: #2 - Hari Krishna Bathini - 2019-05-10 06:02:27 == The udev rule when CPU is added is not triggered because ppc64 does not eject add/remove event when a CPU is hot added/removed. It only ejects online/offline event to user space when CPU is hot added/removed. So, the below udev rules are never triggered when needed: SUBSYSTEM=="cpu", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump-tools.service" SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump-tools.service" Also, with how CPU hot add & remove are handled in ppc64, a udev trigger to reload kdump after CPU is hot removed is NOT necessary. So, fix the CPU hot add case by updating the udev rule and drop the udev rule meant for CPU hot remove in the kdump udev rules file: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try- restart kdump-tools.service" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828596/+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 1655280] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore
** Changed in: makedumpfile (Ubuntu Xenial) 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/1655280 Title: ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Fix Released Status in linux source package in Xenial: Invalid Status in makedumpfile source package in Xenial: In Progress Status in linux source package in Bionic: Invalid Status in makedumpfile source package in Bionic: Fix Released Status in linux source package in Cosmic: Invalid Status in makedumpfile source package in Cosmic: Fix Released Status in linux source package in Disco: Invalid Status in makedumpfile source package in Disco: Fix Released Bug description: [Impact] After a DLPAR memory/CPU add/remove operation, kdump tools need to be restarted or else kdump tools will fail to capture the crash. [Test] == Comment: #0 - Ping Tian Han - 2017-01-09 02:51:00 == ---Problem Description--- Vmcore cannot be saved when triggering bug 150353 on roselp4: Copying data : [ 2.0 %] \/usr/sbin/kdump-config: line 591: 5502 Bus error makedumpfile $MAKEDUMP_ARGS $vmcore_file $KDUMP_CORETEMP [ 512.833872] kdump-tools[5450]: * kdump-tools: makedumpfile failed, falling back to 'cp' [ 573.595449] kdump-tools[5450]: cp: error reading '/proc/vmcore': Bad address [ 573.605717] kdump-tools[5450]: * kdump-tools: failed to save vmcore in /var/crash/201701090223 [ 573.765417] kdump-tools[5450]: * running makedumpfile --dump-dmesg /proc/vmcore /var/crash/201701090223/dmesg.201701090223 [ 574.285506] kdump-tools[5450]: The kernel version is not supported. [ 574.285672] kdump-tools[5450]: The makedumpfile operation may be incomplete. [ 574.285767] kdump-tools[5450]: The dmesg log is saved to /var/crash/201701090223/dmesg.201701090223. [ 574.305422] kdump-tools[5450]: makedumpfile Completed. [ 574.315363] kdump-tools[5450]: * kdump-tools: saved dmesg content in /var/crash/201701090223 [ 574.615688] kdump-tools[5450]: Mon, 09 Jan 2017 02:24:26 -0600 [ 574.705384] kdump-tools[5450]: Rebooting. Stopping ifup for ib0... [ OK ] Stopped ifup for ib0. [ 1008.579897] reboot: Restarting system Contact Information = Ping Tian Han/pt...@cn.ibm.com Carrie Mitsuyoshi/carri...@us.ibm.com ---uname output--- Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = lpar ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. config kdump on roselp4 2. try to trigger bug 150353 *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com Carrie Mitsuyoshi/carri...@us.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. == Comment: #3 - Brahadambal Srinivasan - 2017-01-10 02:42:25 == root@roselp4:~# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinux-4.8.0-34-generic root=UUID=0bcf3431-df8b-499c-9a13-33070f242e0c ro splash quiet crashkernel=384M-:512M root@roselp4:~# dmesg | grep Reser [0.00] Reserving 512MB of memory at 128MB for crashkernel (System RAM: 21760MB) [Regression Potential] The fix applies to makedumpfile, and could impact dump capture. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1655280/+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 1840026] Re: Ubuntu 18.04.2: Unable to boot guest with scsi disk having sgio flag
After having the kernel side of things discussed with the kernel team, the
affecting kernel entry will be marked as 'Won't Fix' for now, too - since the
overall feature and function is not yet completely upstream and the importance
is low anyway.
Once the kernel side of the feature got upstream accepted, it will then
automatically land in a future Ubuntu kernel.
** Changed in: ubuntu-power-systems
Status: Opinion => Won't Fix
--
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/1840026
Title:
Ubuntu 18.04.2: Unable to boot guest with scsi disk having sgio flag
Status in The Ubuntu-power-systems project:
Won't Fix
Status in libvirt package in Ubuntu:
Won't Fix
Status in linux package in Ubuntu:
Won't Fix
Bug description:
== Comment: #0 - SRIKANTH AITHAL - 2019-07-03
22:28:43 ==
---Problem Description---
When we try to boot KVM guest with scsi disk having `sgio="unfiltered"`,
guest fails to boot throwing below error
virsh start vm1 --console
error: Failed to start domain vm1
error: Requested operation is not valid: unpriv_sgio is not supported by this
kernel
Contact Information = srikanth/bssrika...@in.ibm.com
---uname output---
Linux pkvmhab008 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:54:50 UTC
2019 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = witherspoon
---Debugger---
A debugger is not configured
---Steps to Reproduce---
Recreation steps:
1. Using scsi_debug driver to simulate scsi disk
#/sbin/modprobe scsi_debug dev_size_mb=2048 lbpu=1
#lsscsi|grep scsi_debug|awk '{print $6}'
/dev/sdk
2. Using below disk xml,
3. Try booting KVM guest with above disk,
# virsh start vm1 --console
error: Failed to start domain vm1
error: Requested operation is not valid: unpriv_sgio is not supported by this
kernel
Stack trace output:
no
Oops output:
no
System Dump Location:
There was no dump
*Additional Instructions for srikanth/bssrika...@in.ibm.com:
-Attach sysctl -a output output to the bug.
== Comment: #1 - SRIKANTH AITHAL - 2019-07-03
22:30:28 ==
== Comment: #2 - SRIKANTH AITHAL - 2019-07-03
22:31:03 ==
== Comment: #3 - SRIKANTH AITHAL - 2019-07-03
22:32:34 ==
unpriv_sgio is required for KVM guest running as qemu user to be able to
configure to issue any SCSI commands to storages.
== Comment: #5 - Fabiano Almeida Rosas - 2019-07-25
12:46:15 ==
It seems libvirt added support to `unpriv_sgio` but the kernel side of the
feature never got merged. It was then reverted on libvirt's side but the revert
caused issues so they re-enabled the support. As far as I can tell it will
always fail.
Some iterations of the kernel side feature:
https://lwn.net/Articles/533901/
https://lwn.net/Articles/535075/
https://lkml.org/lkml/2013/5/23/294
Libvirt side:
https://www.redhat.com/archives/libvir-list/2013-January/msg00013.html
Revert of the feature:
https://libvirt.org/git/?p=libvirt.git;a=patch;h=ce346623c19f82f4b35f3466e2ee4066847b750c
Unrevert:
https://www.redhat.com/archives/libvir-list/2015-June/msg00814.html
@Srikanth
Is this known to have worked at some point? Because it might be the case that
the distro is carrying these patches downstream. If that is the case I would
like to know which distro + version, so we can compare the setups.
== Comment: #6 - SRIKANTH AITHAL - 2019-07-25
22:35:33 ==
(In reply to comment #5)
> It seems libvirt added support to `unpriv_sgio` but the kernel side of the
> feature never got merged. It was then reverted on libvirt's side but the
> revert caused issues so they re-enabled the support. As far as I can tell it
> will always fail.
>
> Some iterations of the kernel side feature:
> https://lwn.net/Articles/533901/
> https://lwn.net/Articles/535075/
> https://lkml.org/lkml/2013/5/23/294
>
> Libvirt side:
> https://www.redhat.com/archives/libvir-list/2013-January/msg00013.html
>
> Revert of the feature:
> https://libvirt.org/git/?p=libvirt.git;a=patch;
> h=ce346623c19f82f4b35f3466e2ee4066847b750c
>
> Unrevert:
> https://www.redhat.com/archives/libvir-list/2015-June/msg00814.html
>
>
> @Srikanth
> Is this known to have worked at some point? Because it might be the case
> that the distro is carrying these patches downstream. If that is the case I
> would like to know which distro + version, so we can compare the setups.
No, this was uncovered as part of adding new testcases to our existing
test bucket. So we have not executed this testcase before.
== Comment: #8 - Daniel Henrique Barboza - 2019-08-07
15:32:47 ==
The error message "unpriv_sgio is not supported by this kernel" comes from a
Libvirt code that verifies if the file 'unpriv_sgio' exists in the sysfs path
of the device.
[Kernel-packages] [Bug 1841984] Re: [Backport] Crypto VMX Fixes
This topic was today also discussed here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1841488/comments/5
With this ticket opened against disco (still in service, compared to LP 1841488
which is about cosmic, that's no longer in service) I suggest that we close LP
1841488 (set to Invalid) and work on these patches based on this ticket (LP
1841984).
Nevertheless, the disco master-next tree already includes all patches
(they probably came is via a stable upstream release update):
$ git log --oneline | grep -m 1 "fix copy-paste error in CTR mode"
6cef65e crypto: vmx - fix copy-paste error in CTR mode
$ git log --oneline | grep -m 1 "always increment IV as quadword"
b5df7b3 crypto: vmx - CTR: always increment IV as quadword
$ git log --oneline | grep -m 1 "do nosimd fallback manually"
c438f2b crypto: vmx - ghash: do nosimd fallback manually
(
$ git log --oneline | grep -m 1 "Add support for VMS instructions by ASM"
5c380d6 crypto: vmx - Add support for VMS instructions by ASM
)
(Notice that disco master-next ID hashes might be different to upstream
hashes)
Hence this is already in progress and I suggest that we just wait for
the next and upcoming disco/19.10 kernel to land in proposed, test the
proposed kernel to be sure that these commit IDs really solve the
problem, and close this LP once the kernel got rolled out to the main
pocket.
** Also affects: ubuntu-power-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-power-systems
Status: New => In Progress
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: ubuntu-power-systems
Importance: Undecided => High
** Changed in: ubuntu-power-systems
Assignee: (unassigned) => Frank Heimes (frank-heimes)
--
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/1841984
Title:
[Backport] Crypto VMX Fixes
Status in The Ubuntu-power-systems project:
In Progress
Status in linux package in Ubuntu:
In Progress
Bug description:
Ubuntu Disco is missing the fix for "5c380d623ed3 - crypto: vmx - Add
support for VMS instructions by ASM (4 years, 5 months ago) " ... which is fixed by 'crypto: vmx - fix copy-paste error
in CTR mode', it fixes a couple of incorrect branch targets, and usage
of an incorrect vector assembly instruction.
The others two patches ("crypto: vmx - CTR: always increment IV as
quadword ", "crypto: vmx - ghash: do nosimd fallback manually ") fixes
for ghash replaces the fallback mechanism that is used on powerpc an
operation is required to operate in interrupt context.
Not having these patches might lead to data integrity issues.
patches
crypto: vmx - fix copy-paste error in CTR mode
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dcf7b48212c0fab7df69e84fab22d6cb7c8c0fb9
crypto: vmx - CTR: always increment IV as quadword
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=009b30ac7444c17fae34c4f435ebce8e8e2b3250
crypto: vmx - ghash: do nosimd fallback manually
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=357d065a44cdd77ed5ff35155a989f2a763e96ef
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841984/+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 1841488] Re: [Ubuntu18.10][Backport] Crypto VMX Fixes
Closing this ticket (setting to Invalid, since it's about cosmic).
A new ticket got opened that addresses this issue specially for disco: LP
1841984
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841984
** Changed in: linux (Ubuntu)
Status: Incomplete => Invalid
** Changed in: ubuntu-power-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/1841488
Title:
[Ubuntu18.10][Backport] Crypto VMX Fixes
Status in The Ubuntu-power-systems project:
Invalid
Status in linux package in Ubuntu:
Invalid
Bug description:
Cosmic is missing the fix for "5c380d623ed3 - crypto: vmx - Add
support for VMS instructions by ASM (4 years, 5 months ago) " ... which is fixed by 'crypto: vmx - fix copy-paste error
in CTR mode', it fixes a couple of incorrect branch targets, and usage
of an incorrect vector assembly instruction.
The others two patches ("crypto: vmx - CTR: always increment IV as
quadword ", "crypto: vmx - ghash: do nosimd fallback manually ") fixes
for ghash replaces the fallback mechanism that is used on powerpc an
operation is required to operate in interrupt context.
These fixes are important to avoid a potential data integrity issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841488/+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 1841984] Re: [Backport] Crypto VMX Fixes
An updated disco master-next tree now shows the following:
$ git log --oneline | grep -m 1 "do nosimd fallback manually"
ccfd9be crypto: vmx - ghash: do nosimd fallback manually
$ git describe --tags --contains ccfd9be
Ubuntu-5.0.0-26.27~34
$ git log --oneline | grep -m 1 "always increment IV as quadword"
b5df7b3 crypto: vmx - CTR: always increment IV as quadword
$ git describe --tags --contains b5df7b3
Ubuntu-5.0.0-26.27~394
$ git log --oneline | grep -m 1 "fix copy-paste error in CTR mode"
6cef65e crypto: vmx - fix copy-paste error in CTR mode
$ git describe --tags --contains 6cef65e
Ubuntu-5.0.0-24.25~116
That kernel "Ubuntu-5.0.0-26" incl. everything needed and 5.0.0.27 is in disco
proposed:
linux-generic | 5.0.0.27.28 | disco-proposed | s390x
Hence, would you mind re-trying with the latest disco-proposed kernel?
--
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/1841984
Title:
[Backport] Crypto VMX Fixes
Status in The Ubuntu-power-systems project:
In Progress
Status in linux package in Ubuntu:
In Progress
Bug description:
Ubuntu Disco is missing the fix for "5c380d623ed3 - crypto: vmx - Add
support for VMS instructions by ASM (4 years, 5 months ago) " ... which is fixed by 'crypto: vmx - fix copy-paste error
in CTR mode', it fixes a couple of incorrect branch targets, and usage
of an incorrect vector assembly instruction.
The others two patches ("crypto: vmx - CTR: always increment IV as
quadword ", "crypto: vmx - ghash: do nosimd fallback manually ") fixes
for ghash replaces the fallback mechanism that is used on powerpc an
operation is required to operate in interrupt context.
Not having these patches might lead to data integrity issues.
patches
crypto: vmx - fix copy-paste error in CTR mode
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dcf7b48212c0fab7df69e84fab22d6cb7c8c0fb9
crypto: vmx - CTR: always increment IV as quadword
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=009b30ac7444c17fae34c4f435ebce8e8e2b3250
crypto: vmx - ghash: do nosimd fallback manually
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=357d065a44cdd77ed5ff35155a989f2a763e96ef
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841984/+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 1832622] Re: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3)
May I ask which kernel was used while testing on disco - was is the kernel from main/updates or proposed (5.0.0.27)? -- 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/1832622 Title: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3) Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Xenial: Won't Fix Status in linux source package in Bionic: Fix Released Status in qemu source package in Bionic: Fix Committed Status in qemu source package in Cosmic: Won't Fix Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Committed Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * This belongs to the overall context of spectre mitigations and even more the try to minimize the related performance impacts. On ppc64el there is a new chip revision (DD 2.3) which provides a facility that helps to better mitigate some of this. * Backport the patches that will make the feature (if supported by the HW) will pass the capability to the guest - to allow guests that support the improved mitigation to use it. [Test Case] * Start guests with and without this capability * Check if the capability is guest visible as intented * Check if there are any issues on pre DD2.3 HW * Test migrations (IBM outlined the intented paths that will work below) * The problem with the above (and also the reasons I didn't add a list of commands this time) is that it needs special HW (mentioned DD2.3 revision) of the chips which aren't available to us right now. Due to that testing / verification of this on all releases is on IBM [Regression Potential] * Adding new capabilities usually works fine, there are three common pitfalls which here are the regression potential. - (severe) the code would announce a capability that isn't really available. The guest tries to use it and crashes - (medium) several migration paths especially from systems with the new cap to older (un-updated systems) will fail. But that applies to any "from machine with Feature to machine without that feature" and isn't really a new regression. As outlined by IBM below they even tried to make it somewhat compatible (by being a new value in an existing cap) - (low) the guest will see new caps and or facilities. A really odd guest could stumble due to that (would actually be a guest bug then) Overall all of the above was considered by IBM when developing this and should be ok. For archive wide SRU considerations, this has NO effect on non ppc64el. [Other Info] * n/a --- Power9 DD 2.3 CPUs running updated firmware will use a new Spectre v2 mitigation. The new mitigation improves performance of branch heavy workloads, but also requires kernel support in order to be fully secure. Without the kernel support there is a risk of a Spectre v2 attack across a process context switch, though it has not been demonstrated in practice. QEMU portion - platform definition needs to account for this new mitigation action.. so attribute for this needs to be added. In terms of support for virtualisation there are 2 sides, kvm and qemu support. Patch list for each, KVM: 2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to kvmppc_get_cpu_char() This is part of LP1822870 already. QEMU: 8ff43ee404 target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST 399b2896d4 target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS The KVM side is upstream as of v5.1-rc1. The QEMU side is upstream as of v4.0.0-rc0. In terms of migration the state is as follows. In order to specify to the guest to use the count cache flush workaround we use the spapr-cap cap-ibs (indirect branch speculation) with the value workaround. Previously the only valid values were broken, fixed-ibs (indirect branch serialisation) and fixed-ccd (count cache disabled). And add a new cap cap-ccf-assist (count cache flush assist) to specify the availability of the hardware assisted flush variant. Note the the way spapr caps work you can migrate to a host that supports a higher value, but not to one which doesn't support the current value (i.e. only supports lower values). Where for cap-ibs these are defined as: 0 - Broken 1 - Workaround 2 - fixed-ibs 3 - fixed-ccd So the following migrations would be valid for example: broken -> fixed-ccd, broken -> workaround, workaround -> fixed-ccd While the following would be invalid: fixed-ccd -> workaround, workaround ->broken, fixed-ccd -> broken This is done to m
[Kernel-packages] [Bug 1841447] Re: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384"
I can confirm that the messages are gone with kernel "4.15.0.60" (currently in proposed). So it's now just a matter of waiting until the "4.15.0.60" (or later) is rolled out. When that happened I'll change the status to Fix Released. ** Attachment added: "tested-kernel-4.15.0.60-from-proposed.txt" https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841447/+attachment/5285807/+files/tested-kernel-4.15.0.60-from-proposed.txt -- 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/1841447 Title: Periodic Msg "BUG: non-zero pgtables_bytes on freeing mm: -16384" Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: A message "BUG: non-zero pgtables_bytes on freeing mm: -16384" occurs frequently during IPL of Ubuntu 18.04.1 and 18.04.2 and also periodically appear very often on the console device after the IPL has finished, which is very annoying. See the output of the dmesg and journalctl -b commands are attached. Both versions 18.04.1 and 18.04.2 use the same kernel: root@m83lp37:~# uname -a Linux m83lp37 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:03 UTC 2019 s390x s390x s390x GNU/Linux root@m83lp37:~# The problem appears on LPAR as well as on a z/VM guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841447/+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 1828035] Re: StrongSwan with GCM and large packet sizes produces unstable behavior
** Changed in: ubuntu-z-systems Status: Triaged => 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/1828035 Title: StrongSwan with GCM and large packet sizes produces unstable behavior Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Status in strongswan package in Ubuntu: Incomplete Bug description: StrongSwan with GCM and large packet sizes produces unstable behavior when used in Linux native environment. ---uname output--- Linux ubu01 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:29:11 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = 3906 / M04 (z14), LPAR (dedicated) ---Debugger--- A debugger is not configured ---Steps to Reproduce--- On two separate machines (Linux native), install StrongSwan and on both machines, configure the encryption with aes128gcm8 for IPsec. Then run the following command from one of the machine: ``` $# ping -s 1024 ``` Small packet sizes are working as expected. However, anything large (around 1024 bytes or more) are sometimes returning wrong values, or the packets are getting lost. This problem does not occur for ciphers not involving GCM. Userspace tool common name: StrongSwan The userspace tool has the following bit modes: both Userspace package: StrongSwan Userspace tool obtained from project website: na -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828035/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
** Description changed: + SRU Justification: + == + + [Impact] + + * The perf top tool hangs and shows error messages, like 'Not enough + memory for annotating' + + [Fix] + + * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop + fallbacking to kallsyms for vdso symbols lookup" + + [Test Case] + + * start a benchmark (mem_alloc, but it doesn't really matter what) + + * execute perf top in a second terminal + + * the output of perf top is correct + + * now stop the benchmark + + * and perf top shows an error message, like "Not enough memory for + annotating '__irf_end' symbol!)" + + * and perf top can't be exited anymore + + [Regression Potential] + + * The regression potential can be considered as low since this happens + only while using the perf top tool + + * and it is known that the commit (above) fixes the problem + + * and the fix is upstream since 4.19 + + [Other Info] + + * current disco and eoan kernels don't show that problem + + * bisecting result points to above commit + + * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) + _ + perf top hangs and shows error messages - + ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux - ---Steps to Reproduce--- - I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore - + I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 - perf tools: Stop fallbacking to kallsyms for vdso symbols lookup + perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Triaged 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: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf t
[Kernel-packages] [Bug 1828166] Re: perf top problem on z with Ubuntu 18.04
** 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828394] Re: [UBUNTU] qdio: clear intparm during shutdown
** 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 -- 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/1828394 Title: [UBUNTU] qdio: clear intparm during shutdown Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: Description: qdio: clear intparm during shutdown Symptom: Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space". Problem: During shutdown, qdio returns its ccw device back to control by qeth - but doesn't reset the interrupt parameter on the device. If qdio_shutdown() failed to terminate its long-running IO on the ccw_device, qeth will subsequently do so. In this case the IRQ for the IO completion is presented to qeth_irq() with the _old_ interrupt parameter, which gets mis-interpreted as a valid qeth_cmd_buffer pointer. Dereferencing this bogus pointer in qeth_release_buffer() triggers the crash. Solution: When returning the ccw device in qdio_shutdown(), also reset its interrupt parameter. Reproduction: Offline an OSA CHPID with multiple active qeth interfaces. Component: Kernel Upstream-ID: 89286320a236d245834075fa13adb0bdd827ecaa Reported: Ubuntu 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828394/+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 1828394] Re: [UBUNTU] qdio: clear intparm during shutdown
** 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/1828394 Title: [UBUNTU] qdio: clear intparm during shutdown Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: Description: qdio: clear intparm during shutdown Symptom: Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space". Problem: During shutdown, qdio returns its ccw device back to control by qeth - but doesn't reset the interrupt parameter on the device. If qdio_shutdown() failed to terminate its long-running IO on the ccw_device, qeth will subsequently do so. In this case the IRQ for the IO completion is presented to qeth_irq() with the _old_ interrupt parameter, which gets mis-interpreted as a valid qeth_cmd_buffer pointer. Dereferencing this bogus pointer in qeth_release_buffer() triggers the crash. Solution: When returning the ccw device in qdio_shutdown(), also reset its interrupt parameter. Reproduction: Offline an OSA CHPID with multiple active qeth interfaces. Component: Kernel Upstream-ID: 89286320a236d245834075fa13adb0bdd827ecaa Reported: Ubuntu 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828394/+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 1828166] Re: perf top problem on z with Ubuntu 18.04
Hi, perf should be in package linux-tools-common and each kernel versions has a dedicated linux-tool-common) package version. $ dpkg -S $(which perf) linux-tools-common: /usr/bin/perf But on disk it's usually in /usr/bin. Please can you check if it's in with: $ dpkg -L linux-tools-common | grep perf$ /usr/bin/perf In case it's not can you just take it temporarily from the last recent bionic package? wget http://launchpadlibrarian.net/417515745/linux-tools-common_4.15.0-48.51_all.deb dpkg-deb -x ./linux-tools-common_4.15.0-48.51_all.deb I think that would be okay for this pre-test, since the perf tool wasn't touched, but just the kernel. The verification during the SRU process later of course needs to be with the proper package. -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828394] Re: [UBUNTU] qdio: clear intparm during shutdown
** Description changed: - Description: qdio: clear intparm during shutdown + SRU Justification: + + [Impact] + + * Crash in qeth_irq() with "Unable to handle kernel pointer dereference + in virtual kernel address space" + + [Fix] + + * 89286320a236d245834075fa13adb0bdd827ecaa 8928632 "s390/qdio: clear + intparm during shutdown" + + [Test Case] + + * Offline an OSA CHPID with multiple active qeth interfaces. + + [Regression Potential] + + * The regression potential can be considered as very low since it only + affects the s390x platform + + * and there it only affects the (ccW) qeth (OSA) network devices + + * and again this happens if the CHPID is offlined, which usually doesn't + happen during regular operation. + + [Other Info] + + * It is already included in kernel 4.17, hence it's already part of + cosmic, disco and eoan and proven there to work. + + * It needs to be applied to kernel 4.15 to land in 18.04 GA and 16.04.5 HWE. + _ + + Description: qdio: clear intparm during shutdown Symptom: Crash in qeth_irq() with "Unable to handle kernel pointer -dereference in virtual kernel address space". + dereference in virtual kernel address space". Problem: During shutdown, qdio returns its ccw device back to control -by qeth - but doesn't reset the interrupt parameter on the -device. If qdio_shutdown() failed to terminate its -long-running IO on the ccw_device, qeth will subsequently -do so. In this case the IRQ for the IO completion is -presented to qeth_irq() with the _old_ interrupt parameter, -which gets mis-interpreted as a valid qeth_cmd_buffer -pointer. Dereferencing this bogus pointer in -qeth_release_buffer() triggers the crash. + by qeth - but doesn't reset the interrupt parameter on the + device. If qdio_shutdown() failed to terminate its + long-running IO on the ccw_device, qeth will subsequently + do so. In this case the IRQ for the IO completion is + presented to qeth_irq() with the _old_ interrupt parameter, + which gets mis-interpreted as a valid qeth_cmd_buffer + pointer. Dereferencing this bogus pointer in + qeth_release_buffer() triggers the crash. Solution: When returning the ccw device in qdio_shutdown(), also reset -its interrupt parameter. + its interrupt parameter. Reproduction: Offline an OSA CHPID with multiple active qeth interfaces. Component: Kernel Upstream-ID: 89286320a236d245834075fa13adb0bdd827ecaa Reported: Ubuntu 18.04 ** Description changed: SRU Justification: [Impact] * Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space" [Fix] * 89286320a236d245834075fa13adb0bdd827ecaa 8928632 "s390/qdio: clear intparm during shutdown" [Test Case] * Offline an OSA CHPID with multiple active qeth interfaces. [Regression Potential] * The regression potential can be considered as very low since it only affects the s390x platform * and there it only affects the (ccW) qeth (OSA) network devices * and again this happens if the CHPID is offlined, which usually doesn't happen during regular operation. [Other Info] - * It is already included in kernel 4.17, hence it's already part of - cosmic, disco and eoan and proven there to work. + * The patch was upstream accepted with kernel 4.17, hence it's already + part of cosmic, disco and eoan and proven there to work. * It needs to be applied to kernel 4.15 to land in 18.04 GA and 16.04.5 HWE. _ Description: qdio: clear intparm during shutdown Symptom: Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space". Problem: During shutdown, qdio returns its ccw device back to control by qeth - but doesn't reset the interrupt parameter on the device. If qdio_shutdown() failed to terminate its long-running IO on the ccw_device, qeth will subsequently do so. In this case the IRQ for the IO completion is presented to qeth_irq() with the _old_ interrupt parameter, which gets mis-interpreted as a valid qeth_cmd_buffer pointer. Dereferencing this bogus pointer in qeth_release_buffer() triggers the crash. Solution: When returning the ccw device in qdio_shutdown(), also reset its interrupt parameter. Reproduction: Offline an OSA CHPID with multiple active qeth interfaces. Component: Kernel Upstream-ID: 89286320a236d245834075fa13adb0bdd827ecaa Reported: Ubuntu 18.04
[Kernel-packages] [Bug 1828166] Re: perf top problem on z with Ubuntu 18.04
Looks like a dedicated linux-tool-common package is needed, because perf too tight to the kernel ... -- 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/1828166 Title: perf top problem on z with Ubuntu 18.04 Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: SRU Justification: == [Impact] * The perf top tool hangs and shows error messages, like 'Not enough memory for annotating' [Fix] * edeb0c90df3581b821a764052d185df985f8b8dc edeb0c9 "perf tools: Stop fallbacking to kallsyms for vdso symbols lookup" [Test Case] * start a benchmark (mem_alloc, but it doesn't really matter what) * execute perf top in a second terminal * the output of perf top is correct * now stop the benchmark * and perf top shows an error message, like "Not enough memory for annotating '__irf_end' symbol!)" * and perf top can't be exited anymore [Regression Potential] * The regression potential can be considered as low since this happens only while using the perf top tool * and it is known that the commit (above) fixes the problem * and the fix is upstream since 4.19 [Other Info] * current disco and eoan kernels don't show that problem * bisecting result points to above commit * applies cleanly on cosmic, but has a little conflict on bionic (both master-next) _ perf top hangs and shows error messages ---uname output--- Linux weather 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:32:27 UTC 2019 s390x s390x s390x GNU/Linux ---Steps to Reproduce--- I start a benchmark (mem_alloc, but it really doesn't matter) and then issue perf top in a second terminal, the output from perf top is correct. Now I stop the benchmark: perf top shows a error message (Not enough memory for annotating '__irf_end' symbol!) and I can't quit from perf top anymore Following analyse took place: No problem with current kernel . Bi-Secting of perf tool took place and following commit was found: commit edeb0c90df3581b821a764052d185df985f8b8dc (HEAD, refs/bisect/bad) Author: Arnaldo Carvalho de Melo Date: Tue Oct 16 17:08:29 2018 -0300 perf tools: Stop fallbacking to kallsyms for vdso symbols lookup When you apply this patch the issue is gone, however it is contained in these versions: git tag --contains edeb0c90df3581b821 v4.19 v4.20 The level I was debugging was kernel 4.15 which does not contain this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828166/+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 1828394] Re: [UBUNTU] qdio: clear intparm during shutdown
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2019-May/thread.html#100652 ** 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/1828394 Title: [UBUNTU] qdio: clear intparm during shutdown Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: New Bug description: SRU Justification: [Impact] * Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space" [Fix] * 89286320a236d245834075fa13adb0bdd827ecaa 8928632 "s390/qdio: clear intparm during shutdown" [Test Case] * Offline an OSA CHPID with multiple active qeth interfaces. [Regression Potential] * The regression potential can be considered as very low since it only affects the s390x platform * and there it only affects the (ccW) qeth (OSA) network devices * and again this happens if the CHPID is offlined, which usually doesn't happen during regular operation. [Other Info] * The patch was upstream accepted with kernel 4.17, hence it's already part of cosmic, disco and eoan and proven there to work. * It needs to be applied to kernel 4.15 to land in 18.04 GA and 16.04.5 HWE. _ Description: qdio: clear intparm during shutdown Symptom: Crash in qeth_irq() with "Unable to handle kernel pointer dereference in virtual kernel address space". Problem: During shutdown, qdio returns its ccw device back to control by qeth - but doesn't reset the interrupt parameter on the device. If qdio_shutdown() failed to terminate its long-running IO on the ccw_device, qeth will subsequently do so. In this case the IRQ for the IO completion is presented to qeth_irq() with the _old_ interrupt parameter, which gets mis-interpreted as a valid qeth_cmd_buffer pointer. Dereferencing this bogus pointer in qeth_release_buffer() triggers the crash. Solution: When returning the ccw device in qdio_shutdown(), also reset its interrupt parameter. Reproduction: Offline an OSA CHPID with multiple active qeth interfaces. Component: Kernel Upstream-ID: 89286320a236d245834075fa13adb0bdd827ecaa Reported: Ubuntu 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1828394/+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
