[Kernel-packages] [Bug 2064530] Re: Include support for .NET 8 for Ubuntu on Power
** Package changed: linux (Ubuntu) => dotnet8 (Ubuntu) ** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) ** Changed in: dotnet8 (Ubuntu) Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => (unassigned) -- 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/2064530 Title: Include support for .NET 8 for Ubuntu on Power Status in The Ubuntu-power-systems project: New Status in dotnet8 package in Ubuntu: New Bug description: == Comment: #0 - JAMIE L. DOLAN - 2024-05-01 12:19:47 == This is a bug to track adding the feature of .NET 8 to Ubuntu 24.04 - This has already been added for s390x - Customer survey showed strong interest in .NET on Linux on Power, having .NET on Ubuntu on Power will help in adoption of .NET on Power To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064530/+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 2062556] Re: [Ubuntu-24.04] Hugepage memory is not getting released even after destroying the guest!
I just had a look at noble's master-next tree:
$ git remote get-url origin
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble
$ git branch
* master-next
and found that commit 19c1ceeca8ed is already applied:
$ git log --oneline | grep -n "block: Fix page refcounts for unaligned buffers
in __bio_release_pages"
300:19c1ceeca8ed block: Fix page refcounts for unaligned buffers in
__bio_release_pages()
but not yet tagged with (incl. in) any version:
$ git tag --contains 19c1ceeca8ed
$
This is probably because it just came in via upstream stable updates:
$ git show 19c1ceeca8ed | sed '/^diff --git/q'
commit 19c1ceeca8ed31d207859e659482ee83ea1959f5
Author: Tony Battersby
Date: Thu Feb 29 13:08:09 2024 -0500
block: Fix page refcounts for unaligned buffers in __bio_release_pages()
BugLink: https://bugs.launchpad.net/bugs/2060531
[ Upstream commit 38b43539d64b2fa020b3b9a752a986769f87f7a6 ]
Fix an incorrect number of pages being released for buffers that do not
start at the beginning of a page.
Fixes: 1b151e2435fc ("block: Remove special-casing of compound pages")
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Battersby
Tested-by: Greg Edwards
Link:
https://lore.kernel.org/r/86e592a9-98d4-4cff-a646-0c0084328...@cybernetics.com
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Paolo Pisati
diff --git a/block/bio.c b/block/bio.c
And since the lastest tagged Ubuntu kernel version in master-next is:
Ubuntu-6.8.0-31.31
$ git log --oneline | grep -n $(git describe --tags --abbrev=0)
1170:7fdb45c9bbbc (tag: Ubuntu-6.8.0-31.31) UBUNTU: Ubuntu-6.8.0-31.31
commit 19c1ceeca8ed will be automatically part of the next/upcoming
Ubuntu kernel (> Ubuntu-6.8.0-31.31).
With that I'm updating the status of this bug to Fix Committed.
** Changed in: ubuntu-power-systems
Status: New => Fix Committed
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Committed
** Changed in: ubuntu-power-systems
Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage
(ubuntu-power-triage)
** Changed in: linux (Ubuntu)
Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) =>
(unassigned)
** Changed in: linux (Ubuntu)
Importance: Undecided => High
** Changed in: ubuntu-power-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/2062556
Title:
[Ubuntu-24.04] Hugepage memory is not getting released even after
destroying the guest!
Status in The Ubuntu-power-systems project:
Fix Committed
Status in linux package in Ubuntu:
Fix Committed
Bug description:
---Problem Description---
Hugepages memory is not getting released even after destroying the guest
Machine Type = P10 Denali LPAR
---uname output---
Linux ubuntu2404lp3 6.8.0-22-generic #22-Ubuntu SMP Thu Apr 4 22:47:57 UTC
2024 ppc64le ppc64le ppc64le GNU/Linux
---Steps to Reproduce---
1. Create a guest which is backed by hugepages.
2. Destroy the guest
3. execute "free -h" or "cat /proc/meminfo" to see that Hugepage memory is
still getting held.
HugePages_Total: 20480
HugePages_Free:20419
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 2048 kB
Hugetlb:41943040 kB
DirectMap4k: 0 kB
DirectMap64k:52428800 kB
DirectMap2M: 0 kB
DirectMap1G: 0 kB
root@ubuntu2404lp3:~# virsh list --all
Id Name State
---
-ramlp2g1 shut off
-ramlp2g2 shut off
-ramlp2g3 shut off
-ramlp3g3 shut off
root@ubuntu2404lp3:~# free -h
totalusedfree shared buff/cache
available
Mem:48Gi43Gi 4.6Gi 2.6Mi 277Mi
4.6Gi
Swap: 8.0Gi 243Mi 7.8Gi
root@ubuntu2404lp3:~#
This is an issue created by commit 1b151e2435fc ("block: Remove
special-casing of compound pages") that moved the direct-io hugetlb handling
from compound pages to folios.
Following commit has been proposed and merged into 6.9-rc1 which fixes this
issue.
38b43539d64b2fa020b3b9a752a986769f87f7a6("block: Fix page refcounts for
unaligned buffers in __bio_release_pages()")
So the same needs to be backported to the Ubuntu24.04 kernel as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2062556/+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 2062556] Re: [Ubuntu-24.04] Hugepage memory is not getting released even after destroying the guest!
** Also affects: ubuntu-power-systems
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2062556
Title:
[Ubuntu-24.04] Hugepage memory is not getting released even after
destroying the guest!
Status in The Ubuntu-power-systems project:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
---Problem Description---
Hugepages memory is not getting released even after destroying the guest
Machine Type = P10 Denali LPAR
---uname output---
Linux ubuntu2404lp3 6.8.0-22-generic #22-Ubuntu SMP Thu Apr 4 22:47:57 UTC
2024 ppc64le ppc64le ppc64le GNU/Linux
---Steps to Reproduce---
1. Create a guest which is backed by hugepages.
2. Destroy the guest
3. execute "free -h" or "cat /proc/meminfo" to see that Hugepage memory is
still getting held.
HugePages_Total: 20480
HugePages_Free:20419
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 2048 kB
Hugetlb:41943040 kB
DirectMap4k: 0 kB
DirectMap64k:52428800 kB
DirectMap2M: 0 kB
DirectMap1G: 0 kB
root@ubuntu2404lp3:~# virsh list --all
Id Name State
---
-ramlp2g1 shut off
-ramlp2g2 shut off
-ramlp2g3 shut off
-ramlp3g3 shut off
root@ubuntu2404lp3:~# free -h
totalusedfree shared buff/cache
available
Mem:48Gi43Gi 4.6Gi 2.6Mi 277Mi
4.6Gi
Swap: 8.0Gi 243Mi 7.8Gi
root@ubuntu2404lp3:~#
This is an issue created by commit 1b151e2435fc ("block: Remove
special-casing of compound pages") that moved the direct-io hugetlb handling
from compound pages to folios.
Following commit has been proposed and merged into 6.9-rc1 which fixes this
issue.
38b43539d64b2fa020b3b9a752a986769f87f7a6("block: Fix page refcounts for
unaligned buffers in __bio_release_pages()")
So the same needs to be backported to the Ubuntu24.04 kernel as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2062556/+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 2050019] Re: [24.04 FEAT] [SEC2353] zcrypt: extend error recovery to deal with device scans
** Changed in: ubuntu-z-systems 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/2050019 Title: [24.04 FEAT] [SEC2353] zcrypt: extend error recovery to deal with device scans Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: The error recovery of a crypto request currently fails if a device is not available or the device is not completely setup and bound if the device has been discovered due to a bus scan. If, during request handling, a device is lost and a bus scan is triggered the DD must wait for the bus scan (including the device binding) to complete before giving up on reties. This item is important to support life guest relocation where the APQN sets on the source and target guests differ. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2050019/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages (s390x)
** Changed in: ubuntu-z-systems 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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages (s390x) Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Noble: Fix Released Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2060217] Re: NFSv4 fails to mount in noble/s390x
I've noticed that Vasily's commit has meanwhile landed in linux-next, so I took it from there and applied it to noble master-next, but it failed due to changed context. Hence I did a bit of backporting work and got now it in. I triggered appropriate kernel test builds here: https://launchpad.net/~fheimes/+archive/ubuntu/lp2060217 -- 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/2060217 Title: NFSv4 fails to mount in noble/s390x Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: Triaged Status in nfs-utils package in Ubuntu: Invalid Bug description: https://autopkgtest.ubuntu.com/packages/n/nfs-utils/noble/s390x Looks like it has been failing for a long time already. Log: https://autopkgtest.ubuntu.com/results/autopkgtest- noble/noble/s390x/n/nfs-utils/20240404_145924_ef255@/log.gz 339s autopkgtest [14:41:04]: test local-server-client: [--- 340s Killed 340s autopkgtest [14:41:05]: test process requested reboot with marker boot1 364s autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... 372s FAIL: nfs_home not mounted 373s autopkgtest [14:41:38]: test local-server-client: ---] 373s local-server-client FAIL non-zero exit status 1 and 934s autopkgtest [14:50:59]: test kerberos-mount: [--- 935s Initializing database '/var/lib/krb5kdc/principal' for realm 'DEP8', 935s master key name 'K/M@DEP8' 935s Authenticating as principal root/admin@DEP8 with password. 935s Principal "nfs/nfs-server.dep8@DEP8" created. 935s Authenticating as principal root/admin@DEP8 with password. 935s Entry for principal nfs/nfs-server.dep8 with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Entry for principal nfs/nfs-server.dep8 with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Authenticating as principal root/admin@DEP8 with password. 935s Principal "host/nfs-server.dep8@DEP8" created. 935s Authenticating as principal root/admin@DEP8 with password. 935s Entry for principal host/nfs-server.dep8 with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Entry for principal host/nfs-server.dep8 with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 936s exporting *:/storage 938s mount.nfs: mount system call failed for /mnt 938s umount: /mnt: not mounted. 938s autopkgtest [14:51:02]: test kerberos-mount: ---] 939s kerberos-mount FAIL non-zero exit status 32 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/2060217/+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 2060807] Re: [UBUNTU 24.04] s390x: clone clobbers r7
*** This bug is a duplicate of bug 2055175 ***
https://bugs.launchpad.net/bugs/2055175
I strongly believe that this is a duplicate of LP#2055175, which is
meanwhile Fix Released and should be included in the latest noble/24.04
daily images.
glibc in noble (release) is currently (Apr 10th) 2.39-0ubuntu8
and
glibc 2.39-0ubuntu7 changelog incl:
- S390: Do not clobber r7 in clone [BZ #31402] (LP: #2055175)
So I consider this as duplicate and closed/Fix Released.
Please feel free to object, in case you think this is not fixed or if
there is another issue.
** Package changed: linux (Ubuntu) => glibc (Ubuntu)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Also affects: glibc (Ubuntu Noble)
Importance: Undecided
Assignee: Skipper Bug Screeners (skipper-screen-team)
Status: New
** Changed in: glibc (Ubuntu Noble)
Status: New => Fix Released
** Changed in: ubuntu-z-systems
Status: New => Fix Released
** Changed in: glibc (Ubuntu Noble)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
** This bug has been marked a duplicate of bug 2055175
[UBUNTU 23.10] s390x: clone clobbers r7
--
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/2060807
Title:
[UBUNTU 24.04] s390x: clone clobbers r7
Status in Ubuntu on IBM z Systems:
Fix Released
Status in glibc package in Ubuntu:
Fix Released
Status in glibc source package in Noble:
Fix Released
Bug description:
=== Description by ===
On s390x, if clone is called with NULL for child-function or stack argument,
then r7 is clobbered. This bug is needed for glibc 2.37, 2.38, 2.39. Please
pick the committed bugfix.
See
- glibc bugzilla:
Bug 31402 - clone (NULL, NULL, ...) clobbers %r7 register on s390{,x}
https://sourceware.org/bugzilla/show_bug.cgi?id=31402
- glibc-commit on master:
S390: Do not clobber r7 in clone [BZ #31402]
https://sourceware.org/git/?p=glibc.git;a=commit;h=02782fd12849b6673cb5c2728cb750e8ec295aa3
- glibc-commit on release/2.37/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=9a1bdd7df731a4bc60f72dbdc1b849e02cfa9c34
- glibc-commit on release/2.38/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=ee4806e978467d705b26ccb7dfddb9e0a710f8e4
- glibc-commit on release/2.39/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=e0910f1d3278f05439fb434ee528fc9be1b6bd5e
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2060807/+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 2060217] Re: NFSv4 fails to mount in noble/s390x
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Tags added: s390x ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) -- 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/2060217 Title: NFSv4 fails to mount in noble/s390x Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Status in nfs-utils package in Ubuntu: Triaged Bug description: https://autopkgtest.ubuntu.com/packages/n/nfs-utils/noble/s390x Looks like it has been failing for a long time already. Log: https://autopkgtest.ubuntu.com/results/autopkgtest- noble/noble/s390x/n/nfs-utils/20240404_145924_ef255@/log.gz 339s autopkgtest [14:41:04]: test local-server-client: [--- 340s Killed 340s autopkgtest [14:41:05]: test process requested reboot with marker boot1 364s autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... 372s FAIL: nfs_home not mounted 373s autopkgtest [14:41:38]: test local-server-client: ---] 373s local-server-client FAIL non-zero exit status 1 and 934s autopkgtest [14:50:59]: test kerberos-mount: [--- 935s Initializing database '/var/lib/krb5kdc/principal' for realm 'DEP8', 935s master key name 'K/M@DEP8' 935s Authenticating as principal root/admin@DEP8 with password. 935s Principal "nfs/nfs-server.dep8@DEP8" created. 935s Authenticating as principal root/admin@DEP8 with password. 935s Entry for principal nfs/nfs-server.dep8 with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Entry for principal nfs/nfs-server.dep8 with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Authenticating as principal root/admin@DEP8 with password. 935s Principal "host/nfs-server.dep8@DEP8" created. 935s Authenticating as principal root/admin@DEP8 with password. 935s Entry for principal host/nfs-server.dep8 with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 935s Entry for principal host/nfs-server.dep8 with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab. 936s exporting *:/storage 938s mount.nfs: mount system call failed for /mnt 938s umount: /mnt: not mounted. 938s autopkgtest [14:51:02]: test kerberos-mount: ---] 939s kerberos-mount FAIL non-zero exit status 32 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2060217/+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 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`
Fantastic, thanks for re-testing and confirming! Closing this ticket as Fix Released. ** Changed in: ubuntu-power-systems Status: New => Fix Released ** Changed in: linux (Ubuntu) Status: Confirmed => 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/2056491 Title: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block` Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: After I select `Try or Install Ubuntu Server` on a PowerVM ppc64le Power9 or Power10 : error: out of memory. Press any key to continue... OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 6.8.0-11-generic (buildd@bos01-ppc64el-003) (powerpc64le-linux-gnu-gcc-13 (Ubuntu 13.2.0-13ubuntu1) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 (Ubuntu 6.8.0-11.11-generic 6.8.0-rc4) Detected machine type: 0101 command line: BOOT_IMAGE=/casper/vmlinux quiet --- Max number of cores passed to firmware: 256 (NR_CPUS = 2048) Calling ibm,client-architecture-support... done memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0e67 alloc_top: 2000 alloc_top_hi : 2000 rmo_top : 2000 ram_top : 2000 instantiating rtas at 0x1ec3... done prom_hold_cpus: skipped copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x1078 -> 0x1078179e Device tree struct 0x1079 -> 0x107a Quiescing Open Firmware ... Booting Linux via __start() @ 0x0a75 ... [0.019184] plpks: POWER LPAR Platform KeyStore is not supported or enabled [0.114052] SED: plpks not available [0.114507] /dev/root: Can't open blockdev [0.114520] List of all bdev filesystems: [0.114523] ext3 [0.114523] ext2 [0.114525] ext4 [0.114527] squashfs [0.114529] vfat [0.114531] fuseblk [0.114532] [0.114535] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.114540] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-11-generic #11-Ubuntu [0.114545] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.00 (NH1030_017) hv:phyp pSeries [0.114551] Call Trace: [0.114553] [c6403b40] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.114562] [c6403b70] [c01926ec] panic+0x300/0x524 [0.114568] [c6403c10] [c301146c] mount_root_generic+0x208/0x448 [0.114574] [c6403ce0] [c30118d8] prepare_namespace+0x98/0x430 [0.114580] [c6403d70] [c3010820] kernel_init_freeable+0x32c/0x37c [0.114585] [c6403de0] [c00115ec] kernel_init+0x34/0x298 [0.114591] [c6403e50] [c000dfbc] ret_from_kernel_user_thread+0x14/0x1c [0.114596] --- interrupt: 0 at 0x0 [0.117006] pstore: backend (nvram) writing error (-1) [0.119362] Rebooting in 10 seconds.. This is the message from a Power10(9080-HEX), but the same is happening on a PowrerVM-Power9 (9009-22A) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056491/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages (s390x)
This is not incl. in Ubuntu-6.8.0-20.20, but will be included in the next updated 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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages (s390x) Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2059303] Re: [UBUNTU 20.04] SE-tooling: New IBM host-key subject locality (s390-tools)
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu) ** Also affects: s390-tools-signed (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: s390-tools (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: ubuntu-z-systems Importance: Undecided => Critical ** Information type changed from Public to Public Security -- 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/2059303 Title: [UBUNTU 20.04] SE-tooling: New IBM host-key subject locality (s390-tools) Status in Ubuntu on IBM z Systems: New Status in s390-tools package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Bug description: Description: SE-tooling: New IBM host-key subject locality Symptom: On April 24 (z15) / March 29 (z16) user will notice that the tooling for Secure execution will no longer detect that the provided IBM signing key for that generation is a valid IBM signing key. The error message will contain "no IBM signing key found" or similar. The respective tool will reject creating an encrypted request/image as it could not verify the host-key for its validity. This affects genprotimg, pvattest, and pvsecret. Problem: The new IBM signing keys no longer contain 'Poughkeepsie' as 'subject locality' and 'Armonk' is used. The SE tooling checks, beside other things, for the subject in the IBM signing key. If the subject is not the expected one, the certificate is not recognized as a valid IBM signing key. With no valid IBM signing key, the host-key verification cannot succeed and users cannot build trustable SE images and attestation or add-secret requests. Solution: Mitigations are available upstream. The fixes allow Armonk as additional locality in the subject and allow potential mismatches in the locality of revocation list or host-key issuer subject that may still contain Poughkeepsie instead of Armonk. Reproduction: Use a new IBM signing key in the unpatched tooling. The fix is required due to the circumstances described here: https://www.ibm.com/docs/en/linux-on-systems?topic=systems-whats-new#iplsdkwhatsnew__title__2 This is required for all Ubuntu releases in service that support secure execution. Therefore, Ubuntu 20.04 LTS (focal) and above are affected and need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2059303/+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 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
Thanks for testing the '-20' kernel @kowshik.jois and thanks for the updates @arighi and @hariharan.ts. With that I'm closing this ticket (as Fix Released in 6.8.0-20). ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: ubuntu-power-systems Status: Confirmed => 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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job for default target initrd.target. Machine Type = P10 LPAR Contact Information = Kowshik Jois B S kowshik.j...@in.ibm.com ---Steps to Reproduce--- 1. reboot the system 2. Once the system is booted back, look at dmesg ---uname output--- Linux ubuntu2404
[Kernel-packages] [Bug 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
** 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/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2051683] Re: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely
*** This bug is a duplicate of bug 2038583 *** https://bugs.launchpad.net/bugs/2038583 ** 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/2051683 Title: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Make the final step to a 64bit only distro by removing kernel compat support for 31/32 bit. This will mean that statically linked 31/32bit binaries and container images cannot be run anymore. Such a step needs to be done for a major release, and will also be made for the upstream kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051683/+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 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
Hi Kowshik, sorry, just noticed the machine data line in the log: "IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp" Well, there is no proposed "ISO" - "-proposed" is just a special (pre-release) area in the archive for packages, incl. kernel. So I just thought about updating to the -20 kernel post install, rebooting and checking if it still happens. Btw. does the IBM Power kernel team has an opinion about Andrea's comment #4: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2059237/comments/4 (Since there is a good chance that this is also in the upstream kernels). -- 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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job
[Kernel-packages] [Bug 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
Applied for 6.8.0-12.12, so included in -20 (that is atm still in -proposed). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
** Tags added: noble -- 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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job for default target initrd.target. Machine Type = P10 LPAR Contact Information = Kowshik Jois B S kowshik.j...@in.ibm.com ---Steps to Reproduce--- 1. reboot the system 2. Once the system is booted back, look at dmesg ---uname output--- Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux Additional Information: Same trace messages are seen on L2 guest as well. == Comment: - Kowshik Jois B S == Hello Likhitha, The ubuntu bug
[Kernel-packages] [Bug 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
And another quick question: on which systems does that happen? P9 (bare-metal or PowerVM) or P10 (PowerVM) or KVM on Power? -- 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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job for default target initrd.target. Machine Type = P10 LPAR Contact Information = Kowshik Jois B S kowshik.j...@in.ibm.com ---Steps to Reproduce--- 1. reboot the system 2. Once the system is booted back, look at dmesg ---uname output--- Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux Additional Information: Same trace messages are seen on L2 guest as well. == Comment: - Kowshik
[Kernel-packages] [Bug 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
Hello Kowshik Jois, thanks for raising our attention on this. I apologize, but once a Launchpad ticket got closed (for example as Fix Released), like with LP#2055126, it is no longer actively monitored anymore (by our team), hence we missed your additional comments. (I just found your comments, after I explicitly opened it again ...) In addition I personally didn't recognized LP#2052767, since it wasn't opened via the Bugzilla-to-Launchpad bridge, hence wasn't marked as affecting the 'The Ubuntu-power-systems project', which is what we actively monitor. But anyway, each problem needs it's own Launchpad entry, so it was correct to open this one here. (I'll just mark LP#2052767 as a duplicate of this one, LP#2059237). ___ So it looks like this happens with a kernel 6.6 (info taken from LP#2052767: linux-6.6.0 - is this an upstream kernel build that you did by yourself? Since - afair - we never had a kernel 6.6 in noble/24.04, just a 6.7.) and with kernel 6.8.0-11 (from the bug description here) - that is the one we currently have in the daily IOSs. There is already an updated kernel available from our "-proposed" pocket. $ rmadison --arch=ppc64el --suite=noble,noble-proposed linux-generic linux-generic | 6.8.0-11.11+1 | noble | ppc64el linux-generic | 6.8.0-20.20+1 | noble-proposed | ppc64el <== Would you mind installing and trying the 6.8.0-20 from proposed, to see if that (very latest) kernel still shows this 'UBSAN: array-index-out-of-bounds' issue? ** Changed in: ubuntu-power-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/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR
[Kernel-packages] [Bug 2059237] Re: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) ** Changed in: linux (Ubuntu) Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => (unassigned) ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: ubuntu-power-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2059237 Title: [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: == Comment:- Kowshik Jois B S == ---Problem Description--- Below trace messges are observed in dmesg after every reboot. [0.474287] integrity: Unable to open file: /etc/keys/x509_evm.der (-2) [0.475750] Freeing unused kernel image (initmem) memory: 8832K [0.507388] Checked W+X mappings: passed, no W+X pages found [0.507400] Run /init as init process [0.507403] with arguments: [0.507404] /init [0.507405] with environment: [0.507406] HOME=/ [0.507407] TERM=linux [0.507408] BOOT_IMAGE=/vmlinux-6.8.0-11-generic [0.511892] [ cut here ] [0.511904] UBSAN: array-index-out-of-bounds in /build/linux-MzA0lF/linux-6.8.0/arch/powerpc/kernel/module_64.c:353:17 [0.511909] index 0 is out of range for type 'char [*]' [0.511912] CPU: 13 PID: 1 Comm: systemd Not tainted 6.8.0-11-generic #11-Ubuntu [0.511917] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1060.00 (NH1060_013) hv:phyp pSeries [0.511921] Call Trace: [0.511922] [c6683620] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.511931] [c6683650] [c0c7bc58] __ubsan_handle_out_of_bounds+0xc4/0x12c [0.511938] [c6683700] [c005d2a8] module_frob_arch_sections+0x4ec/0x8d0 [0.511943] [c66837e0] [c02b98cc] layout_and_allocate.isra.0+0x38/0x2a8 [0.511948] [c6683850] [c02b9dec] load_module+0x138/0xca0 [0.511953] [c6683990] [c02baca8] init_module_from_file+0xb4/0x14c [0.511958] [c6683a70] [c02baf70] sys_finit_module+0x230/0x48c [0.511963] [c6683b80] [c0033248] system_call_exception+0xe8/0x240 [0.511967] [c6683e50] [c000d15c] system_call_vectored_common+0x15c/0x2ec [0.511972] --- interrupt: 3000 at 0x7879b903b8a8 [0.511977] NIP: 7879b903b8a8 LR: CTR: [0.511980] REGS: c6683e80 TRAP: 3000 Not tainted (6.8.0-11-generic) [0.511984] MSR: 8000f033 CR: 48222428 XER: [0.511993] IRQMASK: 0 GPR00: 0161 7fffd683b580 7879b9166d00 0004 GPR04: 7879b8e0c160 0004 0010 0004 GPR08: 0001 GPR12: 7879b99d3a00 2000 0002 GPR16: 1b5c7d7453e0 7fffd683ba68 GPR20: 1b5c82154ae0 1b5c82142360 GPR24: 7879b957f7b0 1b5c82154ae0 1b5c82142160 GPR28: 7879b8e0c160 0002 1b5c82154ae0 1b5c82142380 [0.512029] NIP [7879b903b8a8] 0x7879b903b8a8 [0.512032] LR [] 0x0 [0.512034] --- interrupt: 3000 [0.512036] ---[ end trace ]--- [0.518326] systemd[1]: Inserted module 'autofs4' [0.521570] systemd[1]: systemd 255.2-3ubuntu2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [0.521583] systemd[1]: Detected virtualization powervm. [0.521589] systemd[1]: Detected architecture ppc64-le. [0.521593] systemd[1]: Running in initrd. [0.521743] systemd[1]: No hostname configured, using default hostname. [0.521789] systemd[1]: Hostname set to . [0.521847] systemd[1]: Initializing machine ID from random generator. [0.600736] systemd[1]: Queued start job for default target initrd.target. Machine Type = P10 LPAR Contact Information = Kowshik Jois B S kowshik.j...@in.ibm.com ---Steps to
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
This LP bug was entirely s390x specific, hence not affecting any other platform. So setting verification again to done, to potentially unblock any further processes. ** Tags removed: verification-needed-jammy-linux-nvidia-6.5 ** Tags added: verification-done verification-done-jammy-linux-nvidia-6.5 -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
This LP bug was entirely s390x specific, hence not affecting any other platform. So setting verification again to done, to potentially unblock any further processes. ** Tags removed: verification-needed-jammy-linux-nvidia-6.5 ** Tags added: verification-done verification-done-jammy-linux-nvidia-6.5 -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config
[Kernel-packages] [Bug 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`
Hi @kowshik.jois, the (daily) images still have the same kernel inside (the 6.8 -11): $ rmadison --arch=ppc64el --suite=noble,noble-proposed linux-generic linux-generic | 6.8.0-11.11+1 | noble | ppc64el linux-generic | 6.8.0-20.20+1 | noble-proposed | ppc64el But there is now a newer kernel (-20), but it is still in -proposed. It takes some time until it transitions to release, and again a bit until it arrives in the ISO. So right now we are waiting until we have the -20 in the ISO, to be able to do more testing ... -- 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/2056491 Title: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block` Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: After I select `Try or Install Ubuntu Server` on a PowerVM ppc64le Power9 or Power10 : error: out of memory. Press any key to continue... OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 6.8.0-11-generic (buildd@bos01-ppc64el-003) (powerpc64le-linux-gnu-gcc-13 (Ubuntu 13.2.0-13ubuntu1) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 (Ubuntu 6.8.0-11.11-generic 6.8.0-rc4) Detected machine type: 0101 command line: BOOT_IMAGE=/casper/vmlinux quiet --- Max number of cores passed to firmware: 256 (NR_CPUS = 2048) Calling ibm,client-architecture-support... done memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0e67 alloc_top: 2000 alloc_top_hi : 2000 rmo_top : 2000 ram_top : 2000 instantiating rtas at 0x1ec3... done prom_hold_cpus: skipped copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x1078 -> 0x1078179e Device tree struct 0x1079 -> 0x107a Quiescing Open Firmware ... Booting Linux via __start() @ 0x0a75 ... [0.019184] plpks: POWER LPAR Platform KeyStore is not supported or enabled [0.114052] SED: plpks not available [0.114507] /dev/root: Can't open blockdev [0.114520] List of all bdev filesystems: [0.114523] ext3 [0.114523] ext2 [0.114525] ext4 [0.114527] squashfs [0.114529] vfat [0.114531] fuseblk [0.114532] [0.114535] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.114540] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-11-generic #11-Ubuntu [0.114545] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.00 (NH1030_017) hv:phyp pSeries [0.114551] Call Trace: [0.114553] [c6403b40] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.114562] [c6403b70] [c01926ec] panic+0x300/0x524 [0.114568] [c6403c10] [c301146c] mount_root_generic+0x208/0x448 [0.114574] [c6403ce0] [c30118d8] prepare_namespace+0x98/0x430 [0.114580] [c6403d70] [c3010820] kernel_init_freeable+0x32c/0x37c [0.114585] [c6403de0] [c00115ec] kernel_init+0x34/0x298 [0.114591] [c6403e50] [c000dfbc] ret_from_kernel_user_thread+0x14/0x1c [0.114596] --- interrupt: 0 at 0x0 [0.117006] pstore: backend (nvram) writing error (-1) [0.119362] Rebooting in 10 seconds.. This is the message from a Power10(9080-HEX), but the same is happening on a PowrerVM-Power9 (9009-22A) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056491/+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 2058944] Re: [UBUNTU 24.04] dbginfo.sh: updates required for /bin/dash shell
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: s390-tools (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => Frank Heimes
(fheimes)
** Changed in: ubuntu-z-systems
Importance: Undecided => High
** Changed in: ubuntu-z-systems
Importance: High => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2058944
Title:
[UBUNTU 24.04] dbginfo.sh: updates required for /bin/dash shell
Status in Ubuntu on IBM z Systems:
New
Status in s390-tools package in Ubuntu:
New
Bug description:
== - 2024-03-25 05:51:16 ==
---Description---
Description: dbginfo.sh: incompatible commands with /bin/dash shell
Symptom: script brakes on file copy
Problem: unpacked data collection
Solution: rewrite in compatible way
Component: s390-tools
the master commit in s390tools:
https://github.com/ibm-s390-linux/s390-tools/commit/1c128c0d11f23f9cf4bb9f4cf89a48b3011c4a99
backport required for all unbuntu using s390-tools v2.31.0
---uname output---
Linux <..> 5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:48 UTC 2023
s390x s390x s390x GNU/Linux
Contact Information = sig...@de.ibm.com
---Debugger---
A debugger is not configured
---Steps to Reproduce---
run dbginfo.sh (as root)
script will fail in last step "Finalizing: Creating archive with
collected data"
check /tnp/DBG*/dbginfo.log of the running script, it shows the error
"Bad substitution" for the line
cp -p "${BASH_SOURCE[0]}" "${WORKPATH}"
Problem: dash does not support array function
array function was addd by commit
https://github.com/ibm-s390-linux/s390-tools/commit/58ef99f76b0765f88b270b003bc7a516e5b36ec4
as part of s390-tools v2.31.0
Machine Type = indipendent
Userspace tool common name: dbginfo.sh
The userspace tool has the following bit modes: na
Userspace tool obtained from project website: na
Userspace rpm: s390-tools
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2058944/+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 2050019] Re: [24.04 FEAT] [SEC2353] zcrypt: extend error recovery to deal with device scans
I've submitted the PR to the kernel teams mailing list: https://lists.ubuntu.com/archives/kernel-team/2024-March/thread.html#149742 ** Changed in: linux (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Kernel Team (canonical-kernel-team) ** 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/2050019 Title: [24.04 FEAT] [SEC2353] zcrypt: extend error recovery to deal with device scans Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: The error recovery of a crypto request currently fails if a device is not available or the device is not completely setup and bound if the device has been discovered due to a bus scan. If, during request handling, a device is lost and a bus scan is triggered the DD must wait for the bus scan (including the device binding) to complete before giving up on reties. This item is important to support life guest relocation where the APQN sets on the source and target guests differ. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2050019/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages (s390x)
Got marked as APPLIED by kernel team (Paolo). -- 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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages (s390x) Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages (s390x)
Patches that are needed for noble/24.04 submitted to the kernel teams mailing list: https://lists.ubuntu.com/archives/kernel-team/2024-March/149667.html https://lists.ubuntu.com/archives/kernel-team/2024-March/thread.html#149667 ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: New => In Progress ** Also affects: linux (Ubuntu Noble) Importance: High Status: In Progress ** Changed in: linux (Ubuntu Noble) 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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages (s390x) Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages (s390x)
** Summary changed: - [24.04 FEAT] Memory hotplug vmem pages + [24.04 FEAT] Memory hotplug vmem pages (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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages (s390x) Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2051835] Re: [24.04 FEAT] Memory hotplug vmem pages
** 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/2051835 Title: [24.04 FEAT] Memory hotplug vmem pages Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: The current s390 specific memory hotplug backend allocates 'struct page' management structures for all standby memory regions, when those standby regions are detected at ipl time. The reason for this is, that setting standby online memory is supposed to succeed especially in memory constrained environments, since lack of free memory is likely the reason why additional memory is brought online. If in such cases 'struct pages' would have to be allocated before memory could be brought up, this would likely fail, and contradict the whole rationale of memory hotplug. However pre-allocating memory for 'struct pages' comes with the downside that for highly unbalanced ratios of online/standby memory a system might even fail to ipl, because there is not enough memory available for all possible struct pages which are required for standby memory. The idea is to improve the situation: when standby memory is brought online, the memory for struct pages (and maybe other management structures) required for this new memory area should be taken from the online memory, instead of pre-allocating them. This would solve the problems with unbalanced ratios as described above. Note: there are intentions to tell customers that they should always define the maximum size of standby memory for their LPAR activation profiles. This would allow for maximum flexibility for all LPARs during runtime, given that the amount of standby memory cannot be changed during runtime. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051835/+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 2056373] Re: Problems with HVCS and hotplugging
** Changed in: ubuntu-power-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056373 Title: Problems with HVCS and hotplugging Status in The Ubuntu-power-systems project: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Status in linux source package in Mantic: Invalid Status in linux source package in Noble: Invalid Bug description: SRU Justification: == [Impact] * HVCS (Hypervisor Virtual Console Server) is broken because the virtual terminal mkvterm fails, caused by pvmutil failing. * When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. * This leads to HVCS never having probe() called. * In addition, HVCS is missing patches/fixes, and is broken without them. [Fix] * Fix one and two is required for focal only, all other for focal and jammy: * 57409d4fb12c 57409d4fb12c185b2c0689e0496878c8f6bb5b58 "powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry" * c5e76fa05b2d c5e76fa05b2df519b9f08571cc57e623c1569faa "powerpc/pseries: Fix of_read_drc_info_cell() to point at next record" * 6a9a733edd46 6a9a733edd46732e906d976dc21a42dd361e53cc "hvcs: Fix hvcs port reference counting" * 760aa5e81f33 760aa5e81f33e0da82512c4288489739a6d1c556 "hvcs: Use dev_groups to manage hvcs device attributes" * 503a90dd619d 503a90dd619d52dcac2cc68bd742aa914c7cd47a "hvcs: Use driver groups to manage driver attributes" * 3a8d3b366ce4 3a8d3b366ce47024bf274eac783f8af5df2780f5 "hvcs: Get reference to tty in remove" * d432228bc7b1 d432228bc7b1b3f0ed06510278ff5a77b3749fe6 "hvcs: Use vhangup in hotplug remove" * 28d49f8cbe9c 28d49f8cbe9c7966f91ee1b5ec2f997f6e55bf9f "hvcs: Synchronize hotplug remove with port free" [Test Plan] * The high level test plan is to run mkvterm with an id. * mkvterm will fail because /dev/hvcs* device nodes are missing. * Details see https://bugs.launchpad.net/bugs/2023243 for more information. Especially the script provided by IBM (see original bug description: `---Steps to Reproduce---`). * IBM will (stress) test the updated kernel(s) provided in -proposed. [Where problems could occur] * The first two commits affect arch/powerpc/platforms/pseries/of_helpers.c and are needed to fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. In case of issues here hotplugging with drmgr might break. * The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. * HVCS, rpadlpar_io, and rpaphp should ideally not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). * The remaning 6 commits are needed for HVCS, that is essentially broken without them. Overall, issues they fix are race conditions, hotplug remove issues, as well as memory leaks. * Please notice that this is entirely ppc64el architecture-specifc. [Other Info] * All the commits listed above are included in mantic and noble. Hence these are set to Invalid. * Meanwhile these requested commits have been added to other kernels and distros. __ ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In
[Kernel-packages] [Bug 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`
** Changed in: linux (Ubuntu) Importance: Undecided => Critical -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056491 Title: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block` Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: After I select `Try or Install Ubuntu Server` on a PowerVM ppc64le Power9 or Power10 : error: out of memory. Press any key to continue... OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 6.8.0-11-generic (buildd@bos01-ppc64el-003) (powerpc64le-linux-gnu-gcc-13 (Ubuntu 13.2.0-13ubuntu1) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 (Ubuntu 6.8.0-11.11-generic 6.8.0-rc4) Detected machine type: 0101 command line: BOOT_IMAGE=/casper/vmlinux quiet --- Max number of cores passed to firmware: 256 (NR_CPUS = 2048) Calling ibm,client-architecture-support... done memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0e67 alloc_top: 2000 alloc_top_hi : 2000 rmo_top : 2000 ram_top : 2000 instantiating rtas at 0x1ec3... done prom_hold_cpus: skipped copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x1078 -> 0x1078179e Device tree struct 0x1079 -> 0x107a Quiescing Open Firmware ... Booting Linux via __start() @ 0x0a75 ... [0.019184] plpks: POWER LPAR Platform KeyStore is not supported or enabled [0.114052] SED: plpks not available [0.114507] /dev/root: Can't open blockdev [0.114520] List of all bdev filesystems: [0.114523] ext3 [0.114523] ext2 [0.114525] ext4 [0.114527] squashfs [0.114529] vfat [0.114531] fuseblk [0.114532] [0.114535] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.114540] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-11-generic #11-Ubuntu [0.114545] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.00 (NH1030_017) hv:phyp pSeries [0.114551] Call Trace: [0.114553] [c6403b40] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.114562] [c6403b70] [c01926ec] panic+0x300/0x524 [0.114568] [c6403c10] [c301146c] mount_root_generic+0x208/0x448 [0.114574] [c6403ce0] [c30118d8] prepare_namespace+0x98/0x430 [0.114580] [c6403d70] [c3010820] kernel_init_freeable+0x32c/0x37c [0.114585] [c6403de0] [c00115ec] kernel_init+0x34/0x298 [0.114591] [c6403e50] [c000dfbc] ret_from_kernel_user_thread+0x14/0x1c [0.114596] --- interrupt: 0 at 0x0 [0.117006] pstore: backend (nvram) writing error (-1) [0.119362] Rebooting in 10 seconds.. This is the message from a Power10(9080-HEX), but the same is happening on a PowrerVM-Power9 (9009-22A) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056491/+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 2056373] Re: Problems with HVCS and hotplugging
SRU request submitted to the Ubuntu kernel team mailing list for mantic, lunar and jammy. https://lists.ubuntu.com/archives/kernel-team/2024-March/thread.html#149437 Changing status to 'In Progress' for jammy and focal. ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: linux (Ubuntu Jammy) 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/2056373 Title: Problems with HVCS and hotplugging Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Mantic: Invalid Status in linux source package in Noble: Invalid Bug description: SRU Justification: == [Impact] * HVCS (Hypervisor Virtual Console Server) is broken because the virtual terminal mkvterm fails, caused by pvmutil failing. * When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. * This leads to HVCS never having probe() called. * In addition, HVCS is missing patches/fixes, and is broken without them. [Fix] * Fix one and two is required for focal only, all other for focal and jammy: * 57409d4fb12c 57409d4fb12c185b2c0689e0496878c8f6bb5b58 "powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry" * c5e76fa05b2d c5e76fa05b2df519b9f08571cc57e623c1569faa "powerpc/pseries: Fix of_read_drc_info_cell() to point at next record" * 6a9a733edd46 6a9a733edd46732e906d976dc21a42dd361e53cc "hvcs: Fix hvcs port reference counting" * 760aa5e81f33 760aa5e81f33e0da82512c4288489739a6d1c556 "hvcs: Use dev_groups to manage hvcs device attributes" * 503a90dd619d 503a90dd619d52dcac2cc68bd742aa914c7cd47a "hvcs: Use driver groups to manage driver attributes" * 3a8d3b366ce4 3a8d3b366ce47024bf274eac783f8af5df2780f5 "hvcs: Get reference to tty in remove" * d432228bc7b1 d432228bc7b1b3f0ed06510278ff5a77b3749fe6 "hvcs: Use vhangup in hotplug remove" * 28d49f8cbe9c 28d49f8cbe9c7966f91ee1b5ec2f997f6e55bf9f "hvcs: Synchronize hotplug remove with port free" [Test Plan] * The high level test plan is to run mkvterm with an id. * mkvterm will fail because /dev/hvcs* device nodes are missing. * Details see https://bugs.launchpad.net/bugs/2023243 for more information. Especially the script provided by IBM (see original bug description: `---Steps to Reproduce---`). * IBM will (stress) test the updated kernel(s) provided in -proposed. [Where problems could occur] * The first two commits affect arch/powerpc/platforms/pseries/of_helpers.c and are needed to fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. In case of issues here hotplugging with drmgr might break. * The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. * HVCS, rpadlpar_io, and rpaphp should ideally not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). * The remaning 6 commits are needed for HVCS, that is essentially broken without them. Overall, issues they fix are race conditions, hotplug remove issues, as well as memory leaks. * Please notice that this is entirely ppc64el architecture-specifc. [Other Info] * All the commits listed above are included in mantic and noble. Hence these are set to Invalid. * Meanwhile these requested commits have been added to other kernels and distros. __ ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging
[Kernel-packages] [Bug 2056373] Re: Problems with HVCS and hotplugging
** Description changed: + SRU Justification: + == + + [Impact] + + * HVCS (Hypervisor Virtual Console Server) is broken because the +virtual terminal mkvterm fails, caused by pvmutil failing. + + * When mkvterm is ran, it ultimately fails because it calls pvmutil +which fails. +pvmutil calls drmgr, and drmgr is adding a slot correctly. +However, when drmgr writes the slot information to ?/add_slot, +the return is -ENODEV. + + * This leads to HVCS never having probe() called. + + * In addition, HVCS is missing patches/fixes, and is broken without + them. + + [Fix] + + * Fix one and two is required for focal only, all other for focal and + jammy: + + * 57409d4fb12c 57409d4fb12c185b2c0689e0496878c8f6bb5b58 +"powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry" + + * c5e76fa05b2d c5e76fa05b2df519b9f08571cc57e623c1569faa +"powerpc/pseries: Fix of_read_drc_info_cell() to point at next record" + + * 6a9a733edd46 6a9a733edd46732e906d976dc21a42dd361e53cc +"hvcs: Fix hvcs port reference counting" + + * 760aa5e81f33 760aa5e81f33e0da82512c4288489739a6d1c556 +"hvcs: Use dev_groups to manage hvcs device attributes" + + * 503a90dd619d 503a90dd619d52dcac2cc68bd742aa914c7cd47a +"hvcs: Use driver groups to manage driver attributes" + + * 3a8d3b366ce4 3a8d3b366ce47024bf274eac783f8af5df2780f5 +"hvcs: Get reference to tty in remove" + + * d432228bc7b1 d432228bc7b1b3f0ed06510278ff5a77b3749fe6 +"hvcs: Use vhangup in hotplug remove" + + * 28d49f8cbe9c 28d49f8cbe9c7966f91ee1b5ec2f997f6e55bf9f +"hvcs: Synchronize hotplug remove with port free" + + [Test Plan] + + * The high level test plan is to run mkvterm with an id. + + * mkvterm will fail because /dev/hvcs* device nodes are missing. + + * Details see https://bugs.launchpad.net/bugs/2023243 for more information. +Especially the script provided by IBM +(see original bug description: `---Steps to Reproduce---`). + + * IBM will (stress) test the updated kernel(s) provided in -proposed. + + [Where problems could occur] + + * The first two commits affect arch/powerpc/platforms/pseries/of_helpers.c +and are needed to fix the hotplugging issue seen when drmgr goes to write +the slot information to /sys/bus/pci/slots/control/add_slot. +In case of issues here hotplugging with drmgr might break. + + * The issue lies in rpadlpar_io and rpaphp calling an of helper function +of_read_drc_info_cell(). Without these commits, the value stored +drc_index_start is incorrect. +This ultimately results in the entire SLOT string being incorrect, +and rpaphp never finding the newly added slot by drmgr. +rpadlpar then returns -ENODEV. +Therefore, HVCS is never probed, and the device nodes are never created. + + * HVCS, rpadlpar_io, and rpaphp should ideally not even need to be loaded +prior to drmgr adding a vio slot. +If rpadlpar_io and rpaphp are not loaded, drmgr will load them. +In addition, if rpadlpar_io and rpaphp register the new slot correctly, +rpadlpar_io will call dlpar_add_vio_slot(), +which calls vio_register_device_node() with the device node. +This is what tells the driver core to init and probe HVCS +(which is needed to create the device nodes). + + * The remaning 6 commits are needed for HVCS, that is essentially +broken without them. +Overall, issues they fix are race conditions, hotplug remove issues, +as well as memory leaks. + + * Please notice that this is entirely ppc64el architecture-specifc. + + [Other Info] + + * All the commits listed above are included in mantic and noble. +Hence these are set to Invalid. + + * Meanwhile these requested commits have been added to other +kernels and distros. + __ + ---Problem Description--- - Issues with HVCS and hotplugging issues. + Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. - When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In addition, HVCS is missing patches, and is broken without them. 8 kernel patches have been identified to fix these issues. - + When mkvterm is ran, it ultimately fails because it calls pvmutil which + fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. + However, when drmgr writes the slot information to ?/add_slot, the + return is -ENODEV. This leads to HVCS never having probe() called. In + addition, HVCS is missing patches, and is broken without them. 8 kernel + patches have been
[Kernel-packages] [Bug 2056373] Re: Problems with HVCS and hotplugging
Currently test kernels are being build for focal/20.04 and jammy/22.04 in this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp2056373 ** Changed in: linux (Ubuntu Focal) Status: Triaged => In Progress ** Changed in: linux (Ubuntu Jammy) Status: Triaged => In Progress ** 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 linux in Ubuntu. https://bugs.launchpad.net/bugs/2056373 Title: Problems with HVCS and hotplugging Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Mantic: Invalid Status in linux source package in Noble: Invalid Bug description: ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In addition, HVCS is missing patches, and is broken without them. 8 kernel patches have been identified to fix these issues. ---uname output--- Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux ---Steps to Reproduce--- Run mkvterm with an id. mkvterm will fail because /dev/hvcs* device nodes are missing. See https://bugs.launchpad.net/ubuntu/+source/powerpc-utils/+bug/2023243 for more information. 2 commits made to arch/powerpc/platforms/pseries/of_helpers.c are needed. These commits fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. This is also why the HVCS device nodes were not being created, as mentioned in the previous bug. The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. Ideally - HVCS, rpadlpar_io, and rpaphp should not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). In addition to the 2 commits mentioned above, 6 HVCS commits are needed. HVCS is essentially broken without them. Issues include race conditions, hotplug remove issues, as well as memory leaks. These commits have been added to other distros after multiple issues were seen. Without these commits, 20.04 will experience the same issues. IBM plans on stress testing these changes after an updated kernel is provided in focal-proposed. --- 2 commits that make changes to arch/powerpc/platforms/pseries/of_helpers.c: powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57409d4fb12c185b2c0689e0496878c8f6bb5b58 powerpc/pseries: Fix of_read_drc_info_cell() to point at next record https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5e76fa05b2df519b9f08571cc57e623c1569faa HVCS commits: hvcs: Fix hvcs port reference counting https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a9a733edd46732e906d976dc21a42dd361e53cc hvcs: Use dev_groups to manage hvcs device attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=760aa5e81f33e0da82512c4288489739a6d1c556 hvcs: Use driver groups to manage driver attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=503a90dd619d52dcac2cc68bd742aa914c7cd47a hvcs: Get reference to tty in remove https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a8d3b366ce47024bf274eac783f8af5df2780f5 hvcs: Use vhangup in hotplug remove
[Kernel-packages] [Bug 2056373] Re: Problems with HVCS and hotplugging
** Summary changed: - Multiple issues found on Ubuntu 20.04 against HVCS + Problems with HVCS and hotplugging -- 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/2056373 Title: Problems with HVCS and hotplugging Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Triaged Status in linux source package in Jammy: Triaged Status in linux source package in Mantic: Invalid Status in linux source package in Noble: Invalid Bug description: ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In addition, HVCS is missing patches, and is broken without them. 8 kernel patches have been identified to fix these issues. ---uname output--- Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux ---Steps to Reproduce--- Run mkvterm with an id. mkvterm will fail because /dev/hvcs* device nodes are missing. See https://bugs.launchpad.net/ubuntu/+source/powerpc-utils/+bug/2023243 for more information. 2 commits made to arch/powerpc/platforms/pseries/of_helpers.c are needed. These commits fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. This is also why the HVCS device nodes were not being created, as mentioned in the previous bug. The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. Ideally - HVCS, rpadlpar_io, and rpaphp should not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). In addition to the 2 commits mentioned above, 6 HVCS commits are needed. HVCS is essentially broken without them. Issues include race conditions, hotplug remove issues, as well as memory leaks. These commits have been added to other distros after multiple issues were seen. Without these commits, 20.04 will experience the same issues. IBM plans on stress testing these changes after an updated kernel is provided in focal-proposed. --- 2 commits that make changes to arch/powerpc/platforms/pseries/of_helpers.c: powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57409d4fb12c185b2c0689e0496878c8f6bb5b58 powerpc/pseries: Fix of_read_drc_info_cell() to point at next record https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5e76fa05b2df519b9f08571cc57e623c1569faa HVCS commits: hvcs: Fix hvcs port reference counting https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a9a733edd46732e906d976dc21a42dd361e53cc hvcs: Use dev_groups to manage hvcs device attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=760aa5e81f33e0da82512c4288489739a6d1c556 hvcs: Use driver groups to manage driver attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=503a90dd619d52dcac2cc68bd742aa914c7cd47a hvcs: Get reference to tty in remove https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a8d3b366ce47024bf274eac783f8af5df2780f5 hvcs: Use vhangup in hotplug remove https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d432228bc7b1b3f0ed06510278ff5a77b3749fe6 hvcs: Synchronize hotplug remove with port free https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28d49f8cbe9c7966f91ee1b5ec2f997f6e55bf9f To manage notifications about this bug go to:
[Kernel-packages] [Bug 2056373] Re: Multiple issues found on Ubuntu 20.04 against HVCS
Hello and many thanks for raising these HVCS issue. I first of all analyzed the commits upstream and in the specific Ubuntu kernel trees and found that focal and to some extend jammy are affected. Mantic and noble are not affected: commit 57409d4fb12c got upstream accepted with v5.5(-rc1) commit c5e76fa05b2d got upstream accepted with v5.7(-rc1) commit 6a9a733edd46 got upstream accepted with v6.3(-rc1) commit 760aa5e81f33 got upstream accepted with v6.3(-rc1) commit 503a90dd619d got upstream accepted with v6.3(-rc1) commit 3a8d3b366ce4 got upstream accepted with v6.3(-rc1) commit d432228bc7b1 got upstream accepted with v6.3(-rc1) commit 28d49f8cbe9c got upstream accepted with v6.3(-rc1) commits/release focal jammy mantic noble 57409d4fb12cn y y y c5e76fa05b2dn y y y 6a9a733edd46n n y y 760aa5e81f33n n y y 503a90dd619dn n y y 3a8d3b366ce4n n y y d432228bc7b1n n y y 28d49f8cbe9cn n y y So I'm adding focal and jammy as targets. ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-power-systems Status: New => Triaged ** Changed in: linux (Ubuntu) Status: New => Triaged ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Triaged => Invalid ** Also affects: linux (Ubuntu Noble) Importance: High Status: Invalid ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Importance: High => Undecided ** Changed in: linux (Ubuntu Mantic) Status: New => Invalid ** Changed in: linux (Ubuntu Focal) Importance: Undecided => High ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Changed in: linux (Ubuntu Focal) Status: New => Triaged ** Changed in: linux (Ubuntu Jammy) Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056373 Title: Multiple issues found on Ubuntu 20.04 against HVCS Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Triaged Status in linux source package in Jammy: Triaged Status in linux source package in Mantic: Invalid Status in linux source package in Noble: Invalid Bug description: ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In addition, HVCS is missing patches, and is broken without them. 8 kernel patches have been identified to fix these issues. ---uname output--- Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux ---Steps to Reproduce--- Run mkvterm with an id. mkvterm will fail because /dev/hvcs* device nodes are missing. See https://bugs.launchpad.net/ubuntu/+source/powerpc-utils/+bug/2023243 for more information. 2 commits made to arch/powerpc/platforms/pseries/of_helpers.c are needed. These commits fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. This is also why the HVCS device nodes were not being created, as mentioned in the previous bug. The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. Ideally - HVCS, rpadlpar_io, and rpaphp should not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). In addition to
[Kernel-packages] [Bug 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Importance: Undecided => Critical ** Tags added: noble ppc64el -- 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/2056491 Title: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block` Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: After I select `Try or Install Ubuntu Server` on a PowerVM ppc64le Power9 or Power10 : error: out of memory. Press any key to continue... OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 6.8.0-11-generic (buildd@bos01-ppc64el-003) (powerpc64le-linux-gnu-gcc-13 (Ubuntu 13.2.0-13ubuntu1) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 (Ubuntu 6.8.0-11.11-generic 6.8.0-rc4) Detected machine type: 0101 command line: BOOT_IMAGE=/casper/vmlinux quiet --- Max number of cores passed to firmware: 256 (NR_CPUS = 2048) Calling ibm,client-architecture-support... done memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0e67 alloc_top: 2000 alloc_top_hi : 2000 rmo_top : 2000 ram_top : 2000 instantiating rtas at 0x1ec3... done prom_hold_cpus: skipped copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x1078 -> 0x1078179e Device tree struct 0x1079 -> 0x107a Quiescing Open Firmware ... Booting Linux via __start() @ 0x0a75 ... [0.019184] plpks: POWER LPAR Platform KeyStore is not supported or enabled [0.114052] SED: plpks not available [0.114507] /dev/root: Can't open blockdev [0.114520] List of all bdev filesystems: [0.114523] ext3 [0.114523] ext2 [0.114525] ext4 [0.114527] squashfs [0.114529] vfat [0.114531] fuseblk [0.114532] [0.114535] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.114540] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-11-generic #11-Ubuntu [0.114545] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 of:IBM,FW1030.00 (NH1030_017) hv:phyp pSeries [0.114551] Call Trace: [0.114553] [c6403b40] [c16b2f28] dump_stack_lvl+0x70/0xb4 (unreliable) [0.114562] [c6403b70] [c01926ec] panic+0x300/0x524 [0.114568] [c6403c10] [c301146c] mount_root_generic+0x208/0x448 [0.114574] [c6403ce0] [c30118d8] prepare_namespace+0x98/0x430 [0.114580] [c6403d70] [c3010820] kernel_init_freeable+0x32c/0x37c [0.114585] [c6403de0] [c00115ec] kernel_init+0x34/0x298 [0.114591] [c6403e50] [c000dfbc] ret_from_kernel_user_thread+0x14/0x1c [0.114596] --- interrupt: 0 at 0x0 [0.117006] pstore: backend (nvram) writing error (-1) [0.119362] Rebooting in 10 seconds.. This is the message from a Power10(9080-HEX), but the same is happening on a PowrerVM-Power9 (9009-22A) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056491/+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 2056441] Re: [UBUNTU 20.04] Cannot use vfio-ccw dasd passthrough for KVM guests under Ubuntu
** Package changed: linux (Ubuntu) => libvirt (Ubuntu)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: libvirt (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2056441
Title:
[UBUNTU 20.04] Cannot use vfio-ccw dasd passthrough for KVM guests
under Ubuntu
Status in Ubuntu on IBM z Systems:
New
Status in libvirt package in Ubuntu:
New
Bug description:
---Problem Description (by far...@us.ibm.com) ---
Cannot use vfio-ccw dasd passthrough for KVM guests under Ubuntu 20.04/22.04
Contact Information = Eric Farman
---uname output---
Linux m34mkvmt5 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 21:05:01 UTC
2022 s390x s390x s390x GNU/Linux
---Additional Hardware Info---
ECKD DASD, connected as a mediated device for KVM device passthrough
Machine Type = IBM z14 (3906) LPAR
---Debugger---
A debugger is not configured
---Steps to Reproduce---
Attempting to spawn a guest with a vfio-ccw hostdev device fails with an
AppArmor policy restriction on both 20.04 and 22.04, for files that QEMU
attempts to open for the device. The failure also occurs when trying to hotplug
such a device, which I'll use in these steps to keep the XML simple:
eric@kvmhost:~# chzdev -ea ca8b
eric@kvmhost:~# echo 0.0.ca8b > /sys/bus/ccw/drivers/dasd-eckd/unbind
eric@kvmhost:~# echo 0.0.0b16 > /sys/bus/css/drivers/io_subchannel/unbind
eric@kvmhost:~# echo 0.0.0b16 > /sys/bus/css/drivers/vfio_ccw/bind
eric@kvmhost:~# echo 11f2d2bc-4083-431d-a023-eff72715c4f0 >
/sys/bus/css/devices/0.0.0b16/mdev_supported_types/vfio_ccw-io/create
eric@kvmhost:~# cat hostdev.xml
eric@kvmhost:~# virsh attach-device guest hostdev.xml
error: Failed to attach device from hostdev.xml
error: internal error: unable to execute QEMU command 'device_add':
s390_ccw_realize: Failed to build initial schib: Invalid argument
eric@kvmhost:~# dmesg | grep DENIED
[ 5949.232089] audit: type=1400 audit(1670350246.709:22): apparmor="DENIED"
operation="open" profile="libvirt-0e995f6d-f85e-4ffe-b612-e07bfd62116a"
name="/sys/devices/css0/0.0.0b16/pimpampom" pid=1497 comm="qemu-system-s39"
requested_mask="r" denied_mask="r" fsuid=64055 ouid=0
While the failure occurs with the pimpampom file for the subchannel,
there are two others that QEMU would attempt to open after this:
eric:qemu$ git grep -B 2 -pn fopen hw/s390x/
hw/s390x/css.c=2577=static int css_sch_get_chpids(SubchDev *sch, CssDevId
*dev_id)
--
hw/s390x/css.c-2585-fid_path =
g_strdup_printf("/sys/bus/css/devices/%x.%x.%04x/chpids",
hw/s390x/css.c-2586- dev_id->cssid,
dev_id->ssid, dev_id->devid);
hw/s390x/css.c:2587:fd = fopen(fid_path, "r");
--
hw/s390x/css.c=2612=static int css_sch_get_path_masks(SubchDev *sch, CssDevId
*dev_id)
--
hw/s390x/css.c-2619-fid_path =
g_strdup_printf("/sys/bus/css/devices/%x.%x.%04x/pimpampom",
hw/s390x/css.c-2620- dev_id->cssid,
dev_id->ssid, dev_id->devid);
hw/s390x/css.c:2621:fd = fopen(fid_path, "r");
--
hw/s390x/css.c=2643=static int css_sch_get_chpid_type(uint8_t chpid, uint32_t
*type,
--
hw/s390x/css.c-2649-fid_path =
g_strdup_printf("/sys/devices/css%x/chp0.%02x/type",
hw/s390x/css.c-2650- dev_id->cssid, chpid);
hw/s390x/css.c:2651:fd = fopen(fid_path, "r");
The first two directories are links to the third, so I made the
following entry in /etc/apparmor.d/local/abstractions/libvirt-qemu
which Works For Me:
eric@kvmhost:~# cat /etc/apparmor.d/local/abstractions/libvirt-qemu
/sys/devices/css0/** r,
This is of course a very broad brush, so perhaps there's a better
deterministic way to the files in question for the subchannel(s) that
are requested. (I apologize if that deterministic logic is tied up in
the "hostdev networks" bug I see here:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398)
For what it's worth, those files are not ones that remain open once
the device is connected to the guest:
eric@kvmhost:~# cat
/etc/apparmor.d/libvirt/libvirt-43b44ca9-d1c2-46f7-a686-2329a5a1d425.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
"/var/log/libvirt/**/guest.log" w,
"/var/lib/libvirt/qemu/domain-guest/monitor.sock" rw,
"/var/lib/libvirt/qemu/domain-3-guest/*" rw,
"/run/libvirt/**/guest.pid" rwk,
"/run/libvirt/**/*.tunnelmigrate.dest.guest" rw,
"/dev/dasdb" rwk,
"/dev/pts/2" rw,
[Kernel-packages] [Bug 2056373] Re: Multiple issues found on Ubuntu 20.04 against HVCS
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) ** Changed in: linux (Ubuntu) Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => (unassigned) ** Changed in: ubuntu-power-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/2056373 Title: Multiple issues found on Ubuntu 20.04 against HVCS Status in The Ubuntu-power-systems project: New Status in linux package in Ubuntu: New Bug description: ---Problem Description--- Issues with HVCS and hotplugging issues. When working on Canonical bug 2023243, it was discovered that mkvterm was not working for multiple reasons. This bug will cover the issues found in HVCS, and hotplugging issues found when drmgr writes the slot information to .../add_slot. When mkvterm is ran, it ultimately fails because it calls pvmutil which fails. pvmutil calls drmgr, and drmgr is adding a slot correctly. However, when drmgr writes the slot information to ?/add_slot, the return is -ENODEV. This leads to HVCS never having probe() called. In addition, HVCS is missing patches, and is broken without them. 8 kernel patches have been identified to fix these issues. ---uname output--- Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux ---Steps to Reproduce--- Run mkvterm with an id. mkvterm will fail because /dev/hvcs* device nodes are missing. See https://bugs.launchpad.net/ubuntu/+source/powerpc-utils/+bug/2023243 for more information. 2 commits made to arch/powerpc/platforms/pseries/of_helpers.c are needed. These commits fix the hotplugging issue seen when drmgr goes to write the slot information to /sys/bus/pci/slots/control/add_slot. This is also why the HVCS device nodes were not being created, as mentioned in the previous bug. The issue lies in rpadlpar_io and rpaphp calling an of helper function of_read_drc_info_cell(). Without these commits, the value stored drc_index_start is incorrect. This ultimately results in the entire SLOT string being incorrect, and rpaphp never finding the newly added slot by drmgr. rpadlpar then returns -ENODEV. Therefore, HVCS is never probed, and the device nodes are never created. Ideally - HVCS, rpadlpar_io, and rpaphp should not even need to be loaded prior to drmgr adding a vio slot. If rpadlpar_io and rpaphp are not loaded, drmgr will load them. In addition, if rpadlpar_io and rpaphp register the new slot correctly, rpadlpar_io will call dlpar_add_vio_slot(), which calls vio_register_device_node() with the device node. This is what tells the driver core to init and probe HVCS (which is needed to create the device nodes). In addition to the 2 commits mentioned above, 6 HVCS commits are needed. HVCS is essentially broken without them. Issues include race conditions, hotplug remove issues, as well as memory leaks. These commits have been added to other distros after multiple issues were seen. Without these commits, 20.04 will experience the same issues. IBM plans on stress testing these changes after an updated kernel is provided in focal-proposed. --- 2 commits that make changes to arch/powerpc/platforms/pseries/of_helpers.c: powerpc/pseries: Fix bad drc_index_start value parsing of drc-info entry https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57409d4fb12c185b2c0689e0496878c8f6bb5b58 powerpc/pseries: Fix of_read_drc_info_cell() to point at next record https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5e76fa05b2df519b9f08571cc57e623c1569faa HVCS commits: hvcs: Fix hvcs port reference counting https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a9a733edd46732e906d976dc21a42dd361e53cc hvcs: Use dev_groups to manage hvcs device attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=760aa5e81f33e0da82512c4288489739a6d1c556 hvcs: Use driver groups to manage driver attributes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=503a90dd619d52dcac2cc68bd742aa914c7cd47a hvcs: Get reference to tty in remove https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a8d3b366ce47024bf274eac783f8af5df2780f5 hvcs: Use vhangup in hotplug remove https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d432228bc7b1b3f0ed06510278ff5a77b3749fe6 hvcs: Synchronize hotplug remove with port free
[Kernel-packages] [Bug 1903288] Re: [24.04] Power guest secure boot with static keys: kernel portion
Closing in favor of a solution based on dynamic keys. ** Changed in: ubuntu-power-systems Status: Incomplete => Invalid ** Changed in: linux (Ubuntu) Status: Expired => 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/1903288 Title: [24.04] Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Invalid Status in linux package in Ubuntu: Invalid Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 2051683] Re: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely
*** This bug is a duplicate of bug 2038583 *** https://bugs.launchpad.net/bugs/2038583 ** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2051683 Title: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Make the final step to a 64bit only distro by removing kernel compat support for 31/32 bit. This will mean that statically linked 31/32bit binaries and container images cannot be run anymore. Such a step needs to be done for a major release, and will also be made for the upstream kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051683/+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 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2027926] Re: [24.04 FEAT] [VS2308] KVM: Implement counters for nested guest shadow events
Updating status to Fix Released, since a kernel 6.8 version has landed in noble-release: linux-generic | 6.8.0-11.11+1 | noble | amd64, arm64, armhf, ppc64el, s390x ** 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/2027926 Title: [24.04 FEAT] [VS2308] KVM: Implement counters for nested guest shadow events Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Guest-3 memory needs to be represented by shadow page tables in the Guest-1 hypervisor. These shadow tables are discarded in certain conditions and need to be rebuilt in consequence, which negatively impacts the nested guest's performance. KVM performance counters for the shadow/unshadow events can help to diagnose performance issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2027926/+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 2038587] Re: Turning COMPAT_32BIT_TIME off on ppc64el
** 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/2038587 Title: Turning COMPAT_32BIT_TIME off on ppc64el Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: This will prevent existing 32-bit powerpcle binaries to operate correctly, if they are still using 32bit time. And even exists? 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2038587/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
** 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic, the kernel code did not require backporting due to the base kernel version already containing it, but the
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 1853306] Re: [22.04 FEAT] Enhanced Interpretation for PCI Functions on s390x - kernel part
This bug affects s390x only, hence I'm updating all further verification requests to done, to unblock potential ongoing processes. ** Tags removed: verification-needed-jammy-linux-mtk ** Tags added: verification-done-jammy-linux-mtk -- 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/1853306 Title: [22.04 FEAT] Enhanced Interpretation for PCI Functions on s390x - kernel part Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Jammy: Fix Released Status in linux source package in Kinetic: Won't Fix Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Bug description: [ Impact ]  * Currently the PCI passthrough implementation for s390x is based on    intercepting PCI I/O instructions, which leads to a reduced I/O performance    compared to the execution of PCI instructions directly in LPAR.  * Hence users may face I/O bottlenecks when using PCI devices in passthrough    mode based on the current implementation.  * For avoiding this and to improve performance, the interpretive execution    of the PCI store and PCI load instructions get enabled.  * A further improvement is achieved by enabling the Adapter-Event-Notification    Interpretation (AENI).  * Since LTS releases are the main focus for stable and long running KVM    workloads, it is highly desired to get this backported to the jammy kernel    (and because the next LTS is still some time away). [ Test Plan ] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only avaialble on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusuable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) Testing will include the following scenarios specifically for ISM devices: 1) Testing of SMC-D v1 fallback: Using 2 ISM devices on the same VCHID that share a PNETID, create 2 guests and pass one ISM device via vfio-pci device to each guest. Establish TCP connectivity between the 2 guests using the libvirt default network, and then use smc_run (https://manpages.ubuntu.com/manpages/jammy/man8/smc_run.8.html) to run an iperf workload between the 2 guests (will include both short workloads and longer-running workloads). Verify that SMC-D transfer was used between the guests instead of TCP via 'smcd stats' (https://manpages.ubuntu.com/manpages/jammy/man8/smcd.8.html) 2) Testing of SMC-D v2: Same as above, but using 2 ISM devices on the same VCHID that have no PNETID specified Testing will include the following scenarios specifically for RoCE devices: 1) Ping testing: Using 2 RoCE VFs that share a common network, create 2 guests and pass one RoCE
[Kernel-packages] [Bug 1639924] Re: Kernel livepatch support for for s390x
This bug affects s390x only, hence I'm updating all further verification requests to done, to unblock potential ongoing processes. ** Tags removed: verification-needed-focal-linux-aws-5.15 verification-needed-jammy verification-needed-jammy-linux-mtk ** Tags added: verification-done-focal-linux-aws-5.15 verification-done-jammy verification-done-jammy-linux-mtk -- 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/1639924 Title: Kernel livepatch support for for s390x Status in Ubuntu on IBM z Systems: Fix Released Status in gcc-11 package in Ubuntu: Fix Released Status in kpatch package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in gcc-11 source package in Jammy: Fix Released Status in kpatch source package in Jammy: Invalid Status in linux source package in Jammy: Fix Released Status in gcc-11 source package in Kinetic: Fix Released Status in kpatch source package in Kinetic: Invalid Status in linux source package in Kinetic: Fix Released Bug description: [ Impact ]  * kpatch upstream has gained support for more architectures which we would like to enable on LTS release. Since building livepatches using the kpatch tooling makes the most sense on LTS kernels.  * This SRU is to enable s390x builds of kpatch on kinetic & jammy.  * Separately linux kernel patches for s390x will also be backported to the GA kernel, whilst hwe-5.19 kernel already has all bugfixes to support livepatches. [ Test Plan ]  * Attempt to run and load sample integration livepatches from the kpatch integration source code, against v5.15 & v5.19 kernels. These should succeed on:  - amd64 jammy v5.15  - amd64 & s390x jammy v5.19  - amd64 & s390x kinetic v5.19 [ Where problems could occur ]  * The newly generated livepatches produced by this kpatch may have different content (more or less sections/sybmols/relocations/etc), but remain compatible with all prior kernels and tool-chains.  * This is a fairly large upstream update to the tooling.  * One command line option to kpatch-build is no longer supported '-e', instead long form command line option must be used '--oot- module'. And '--ott-module-src' becomes mandatory in such cases, previously '--sourcedire' was required. Additional command line options added '--oot-module-src, -R|--non- replace'. '--skip-gcc-check' is still supported but prints warnings, it is deprecated in favour of '--skip-compiler-check'. kpatch-cc utility is added, which is a toolchain wrapper. Thus adjustments might be needed to scripts used to invoke and create kpatch modules.  * Majority of non-test/non-doc changes are to do with:    - add support for s390x and 32bit powerpc    - add support for newer kernels and compilers (support & bugfixes to various sections and symbols)    - more strict checking and bugfixes w.r.t. livepatch generation    - refactoring and better build support for cross-compiled modules, compilation for various linux distributions, and code cleanups. * Some of the fixes from these new upstream releases have already been cherry-picked in the kpatch, but others might soon be needed on x84, i.e. to support gcc-12 built kernels. $ git log --no-merges --oneline v0.8.0..v0.9.7 -- kmod/ kpatch- build/ > shortlog.txt d46fea98ef kpatch-build: strengthen conditions for changed sections 9fac261ed0 kpatch-build: rela section could disappear after patched fe45029b4d kpatch-build: fix KBUILD_MODNAME for OOT modules 8cc0fedefb kpatch-build: use err.h instead of error.h for musl support 07433e98c0 kpatch-cc: fix stripping of source tree prefix 33368a88cd create-diff-object: add support for .return_sites section (x86) e921c557f9 macros: tweak syscall patching macros a1171b112e create-diff-object: Create missing section symbol 0308d52bcd kpatch/s390: Enable kpatch build support b0330ab18e kpatch/s390: Add additional bundled symbols. eb4a85f778 kpatch/s390: Add exclusion lists f0d00a9290 kpatch/s390: Add initial support for kpatch 10002f5aa6 kpatch/s390: Add gcc prerequisite flags for kpatch c6d0b5450b lookup: fix symtab parsing 52863dace0 create-diff-object: fix endianness in kpatch_no_sibling_calls_ppc64le() 017015a725 create-diff-object: make kpatch_check_relocations() more precise f0e3da336c create-diff-object: fix string extraction 86d5208b46 create-diff-object: error on symbol conversion failure 325bccd89d create-diff-object: skip conversion for sections which never have symbols 8508abd3b1 create-diff-object: allow converstion of empty symbols 8d5a628bde create-diff-object: add extra check for symbol conversion edge case 01427d50a1 create-diff-object: move addend math to a new function bec6488af6 create-diff-object: add rela_insn() error check 6b1895a6b7 create-diff-object: convert
[Kernel-packages] [Bug 1996071] Re: [UBUNTU 20.04] boot: Add s390x secure boot trailer
This bug only affected s390x, updating all other verification requests to done (to unblock potential processes). ** Tags removed: verification-needed-jammy verification-needed-jammy-linux-mtk ** Tags added: verification-done-jammy verification-done-jammy-linux-mtk -- 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/1996071 Title: [UBUNTU 20.04] boot: Add s390x secure boot trailer Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Released Status in linux source package in Jammy: Fix Released Status in linux source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact]  * Secure boot of Linux on s390x will no longer be possible    with an upcoming IBM zSystems firmware update. [Fix]  * aa127a069ef3 aa127a069ef312aca02b730d5137e1778d0c3ba7 "s390/boot: add secure boot trailer"    for kinetic and jammy  * https://launchpadlibrarian.net/633020900/0001-s390-boot-add-secure-boot-trailer.patch    backport for focal [Test Plan]  * An IBM z15 or LinuxONE III LPAR with zFCP/SCSI disk storage is required.  * Ensure that 'Enable Secure Boot for Linux' is marked in case    'SCSI Load' is selected at the HMCs Load task and Activation Profile.  * Perform an Ubuntu Server installation, either 20.04 or 22.04    (latest ISO).    It will be a secure boot installation by default in case    'Enable Secure Boot for Linux' was marked.  * Check sysfs:    /sys/firmware/ipl/has_secure   '1' indicates hw support for secure boot, otherwise '0'    /sys/firmware/ipl/secure   '1' indicates that secure IPL was successful, otherwise '0'  * Navigate to the HMC task 'System information'    and check the active firmware release.  * Ensure that Ubuntu is still bootable in secure-boot mode    with the updated firmware active,    by for example doing a reboot after the firmware upgrade. * There is also a way to test the trailer on systems that do not have the updated firmware yet - in this case use the following script: https://launchpadlibrarian.net/633126861/check_sb_trailer.sh [Where problems could occur]  * The 'trailer' might be broken, invalid or in a wrong format    and can't be identified or read properly,    or may cause issues while compressing/decompressing the kernel.  * In worst case secure boot might become broken,    even on systems that are still on the unpatched firmware level.  * Or secure boot will become broken in general. [Other Info]  * The above commit was upstream accepted with v6.1-rc3.  * And it got tagged for upstream stable with:    "Cc: # 5.2+"  * But since this bug is marked as critical, and the patch is relatively    short, traceable and s390x-specific, I'll go ahead and submit this    patch for Jammy and Focal ahead of upstream stable.  * Since on focal file 'vmlinux.lds.S' is at a different location    'arch/s390/boot/compressed/' instead of 'arch/s390/boot/'    and the context is slightly different, the backport is needed.  * It's planned to have kernel 6.2 in lunar (23.04), hence it will have    the patch incl. when at the planned target level. __ Description: boot: Add secure boot trailer Symptom: Secure boot of Linux will no longer be possible with an upcoming    IBM Z firmware update. Problem: New IBM Z firmware requires signed bootable images to contain a    trailing data block with a specific format. Solution: Add the trailing data block to the Linux kernel image. Reproduction: Apply latest firmware, perform IPL with Secure Boot enabled. Fix: available upstream with Upstream-ID: aa127a069ef312aca02b730d5137e1778d0c3ba7 Preventive:yes Date: 2022-10-27 Author:Peter Oberparleiter Component: kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1996071/+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 1984103] Re: [UBUNTU 22.04] s390/qeth: cache link_info for ethtool
his bug only affected s390x, updating all other verification requests to
done (to unblock potential processes).
** Tags removed: verification-needed-jammy-linux-mtk
** Tags added: verification-done-jammy-linux-mtk
--
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/1984103
Title:
[UBUNTU 22.04] s390/qeth: cache link_info for ethtool
Status in Ubuntu on IBM z Systems:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Released
Status in linux source package in Kinetic:
Fix Released
Bug description:
== SRU Justification ==
Since commit e6e771b3d897 ("s390/qeth: detach netdevice while card is
offline") there was a timing window during recovery, that qeth_query_card_info
could be sent to the card, even before it was ready for it, leading to a
failing cardrecovery. There is evidence that this window was hit, as not
all callers of get_link_ksettings() check for netif_device_present.
This patch (Mainline commit 7a07a29e4f67) fixes the regression caused
by commit e6e771b3d897.
Commit 7a07a29e4f67 is in mainline as of v6.0-rc1.
This patch is being requested in Jammy 5.15 and Kinetic 5.19.
== Fix ==
7a07a29e4f67 ("s390/qeth: cache link_info for ethtool")
== Regression Potential ==
Low. This patch has been accepted in upstream stable and is limited to
the s390/qeth card.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
== Comment: #0 - J?rn Siglen - 2022-08-09 07:38:27 ==
+++ This bug was initially created as a clone of Bug #199319 +++
Description: s390/qeth: cache link_info for ethtool
Symptom: lost of IP connection and log entries in journalctl:
  kernel: qeth 0.0.0365: The qeth device driver failed to
  recover an error on the device
Problem: Since commit e6e771b3d897
 ("s390/qeth: detach netdevice while card is offline")
   there was a timing window during recovery, that
   qeth_query_card_info could be sent to the card, even before it
   was ready for it, leading to a failing card recovery. There is
   evidence that this window was hit, as not all callers of
   get_link_ksettings() check for netif_device_present.
Solution: Use cached values in qeth_get_link_ksettings(), instead of
   calling qeth_query_card_info() and falling back to default
   values in case it fails. Link info is already updated when the
   card goes online, e.g. after STARTLAN (physical link up). Set
   the link info to default values, when the card goes offline or
   at STOPLAN (physical link down). A follow-on patch will improve
   values reported for link down.
   Fixes: e6e771b3d897
   ("s390/qeth: detach netdevice while card is offline")
Reproduction: enforce a eth device recvoery, while running ethtool multiple
   times in parallel and using iperf to get load on the interface.
Upstream-ID: 7a07a29e4f6713b224f3bcde5f835e777301bdb8
https://lore.kernel.org/all/20220805184504.7f6f2...@kernel.org/T/#m2e3799a38d1d4630822db50f9a5d9b2ca018252f
applicable for most kernel > 3.14
== Comment: #3 - J?rn Siglen - 2022-08-09 07:54:41 ==
the inital update came in with kernel 5.1 upstream, but we found it
backported in many older kernel versions
== Comment: #4 - J?rn Siglen - 2022-08-09 08:03:09 ==
the acceptance info of the patch can be found here:
https://lore.kernel.org/all/20220805184504.7f6f2...@kernel.org/T/#m2e3799a38d1d4630822db50f9a5d9b2ca018252f
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1984103/+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 2003374] Re: Undefined Behavior Sanitizer (UBSAN) causes failure to match symbols
** Description changed: [ Impact ] Â * When UBSAN is enabled in an s390x kernel configuration, kpatch-build can fail to find matching symbols in the vmlinux symbol table (see attached example_livepatch.patch). This was discovered in both Jammy 5.15 and Kinetic 5.19 kernels, where UBSAN was first enabled (releases up to Focal did not enable UBSAN). See attached kpatch-build console output (output.log) and kpatch-build log (build.log). - * Disabling UBAAN in s390x kernel configurations resolved the issue for + * Disabling UBSAN in s390x kernel configurations resolved the issue for both Jammy 5.15 and Kinetic 5.19. Possibly this could be fixed in kpatch/kpatch-build to continue to enable UBSAN while still allowing Livepatch functionality. [ Test Plan ] Â * Use kpatch-build testcases to build and load a fs/proc/meminfo.c Livepatch on s390x kernel (see attached example_livepatch.patch). This should be successful. [ Where problems could occur ] Â * A fix in kpatch/kpatch-build to properly handle UBSAN objects shouldn't yield any regressions. If UBSAN is disabled to ultimately get past this issue, it could lead to undefined behavior not being caught. -- 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/2003374 Title: Undefined Behavior Sanitizer (UBSAN) causes failure to match symbols Status in dh-kpatches: Unknown Status in Ubuntu on IBM z Systems: Fix Committed Status in kpatch package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Status in kpatch source package in Jammy: In Progress Status in linux source package in Jammy: Fix Released Status in kpatch source package in Kinetic: Won't Fix Bug description: [ Impact ] Â * When UBSAN is enabled in an s390x kernel configuration, kpatch- build can fail to find matching symbols in the vmlinux symbol table (see attached example_livepatch.patch). This was discovered in both Jammy 5.15 and Kinetic 5.19 kernels, where UBSAN was first enabled (releases up to Focal did not enable UBSAN). See attached kpatch-build console output (output.log) and kpatch-build log (build.log). * Disabling UBSAN in s390x kernel configurations resolved the issue for both Jammy 5.15 and Kinetic 5.19. Possibly this could be fixed in kpatch/kpatch-build to continue to enable UBSAN while still allowing Livepatch functionality. [ Test Plan ] Â * Use kpatch-build testcases to build and load a fs/proc/meminfo.c Livepatch on s390x kernel (see attached example_livepatch.patch). This should be successful. [ Where problems could occur ] Â * A fix in kpatch/kpatch-build to properly handle UBSAN objects shouldn't yield any regressions. If UBSAN is disabled to ultimately get past this issue, it could lead to undefined behavior not being caught. To manage notifications about this bug go to: https://bugs.launchpad.net/dh-kpatches/+bug/2003374/+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 2013603] Re: Kernel livepatch ftrace graph fix
This bug only affected s390x, updating all other verification requests to done (to unblock potential processes). ** Tags removed: verification-needed-focal-linux-aws-5.15 verification-needed-jammy verification-needed-jammy-linux-mtk ** Tags added: verification-done-focal-linux-aws-5.15 verification-done-jammy verification-done-jammy-linux-mtk -- 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/2013603 Title: Kernel livepatch ftrace graph fix Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Bug description: [Impact] * Additional patch required to support Livepatch for s390x * Fixes Livepatch transition issues when using ftrace graph tracing [Test Case] * Compile test * Boot test * Test a Livepatch (patch to /proc/meminfo module) * Test Livepatch from ftrace graphed function (via https://github.com/SUSE/qa_test_klp/, klp_tc_10.sh) [Where things could go wrong] * Functionality already exists upstream, once kernel is boot and Livepatch tested - should have no regressions [Other info] * Additional required patch was identified (https://github.com/dynup/kpatch/commit/324a43714b1227b5688e22966a5ee4414c8861d1) due to ftrace graph livepatch transition issue (https://github.com/SUSE/qa_test_klp/issues/17). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2013603/+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 2013088] Re: kernel: fix __clear_user() inline assembly constraints
This bug only affected s390x, updating all other verification requests to done (to unblock potential processes). ** Tags removed: verification-needed-focal verification-needed-focal-linux-aws-5.15 verification-needed-jammy-linux-mtk verification-needed-kinetic ** Tags added: verification-done-focal verification-done-focal-linux-aws-5.15 verification-done-jammy-linux-mtk verification-done-kinetic -- 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/2013088 Title: kernel: fix __clear_user() inline assembly constraints 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 Focal: Fix Released Status in linux source package in Jammy: Fix Released Status in linux source package in Kinetic: Fix Released Status in linux source package in Lunar: Fix Released Bug description: SRU Justification: == [ Impact ]  * In case clear_user() crosses two pages and faults on the second page the kernel may write lowcore contents to the first page, instead of    clearing it.  * The __clear_user() inline assembly misses earlyclobber constraint    modifiers. Depending on compiler and compiler options this may lead to    incorrect code which copies kernel lowcore contents to user space instead of clearing memory, in case clear_user() faults. [Fix] * For Kinetic and Jammy cherrypick of 89aba4c26fae 89aba4c26fae4e459f755a18912845c348ee48f3 "s390/uaccess: add missing earlyclobber annotations to __clear_user()" * For Focal and Bionic a backport of the above commit is needed: https://launchpadlibrarian.net/659551648/s390-uaccess.patch [ Test Plan ] * A test program in C is needed and used for testing. * The test will be done by IBM. [ Where problems could occur ]  * The modification is limited to function 'long __clear_user'.  * And there, just to one inline assembly constraints line.  * This is usually difficult to trace.  * A erroneous modification may lead to a wrong behavior in    'long __clear_user',  * and maybe returning a wrong size (in uaccess.c). [ Other Info ]  * This affects all Ubuntu releases in service, down to 18.04.  * Since we are close to 23.04 kernel freeze, I submit a patch request for    23.04 separately, and submit the SRU request for the all other    Ubuntu releases later. __ Description: kernel: fix __clear_user() inline assembly constraints Symptom: In case clear_user() crosses two pages and faults on the    second page the kernel may write lowcore contents to the    first page, instead of clearing it. Problem: The __clear_user() inline assembly misses earlyclobber    constraint modifiers. Depending on compiler and compiler    options this may lead to incorrect code which copies kernel    lowcore contents to user space instead of clearing memory,    in case clear_user() faults. Solution: Add missing earlyclobber constraint modifiers. Preventive:yes Upstream-ID: 89aba4c26fae4e459f755a18912845c348ee48f3 Affected Releases:    18.04    20.04    22.04    22.10    23.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2013088/+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 2051683] Re: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely
*** This bug is a duplicate of bug 2038583 *** https://bugs.launchpad.net/bugs/2038583 ** Information type changed from Private to Public ** This bug has been marked a duplicate of bug 2038583 Turning COMPAT_32BIT_TIME off on 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/2051683 Title: [24.04 FEAT] [LDP2406] 64bit Only Distro - Remove 31/32bit Support Completely Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: Make the final step to a 64bit only distro by removing kernel compat support for 31/32 bit. This will mean that statically linked 31/32bit binaries and container images cannot be run anymore. Such a step needs to be done for a major release, and will also be made for the upstream kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051683/+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 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
** Changed in: ubuntu-z-systems Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2055175] Re: [UBUNTU 23.10] s390x: clone clobbers r7
** Package changed: linux (Ubuntu) => glibc (Ubuntu)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: glibc (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2055175
Title:
[UBUNTU 23.10] s390x: clone clobbers r7
Status in Ubuntu on IBM z Systems:
New
Status in glibc package in Ubuntu:
New
Bug description:
=== Description by s...@de.ibm.com ==
On s390x, if clone is called with NULL for child-function or stack
argument, then r7 is clobbered. This bug is needed for glibc 2.37,
2.38, 2.39. Please pick the committed bugfix.
See
- glibc bugzilla:
Bug 31402 - clone (NULL, NULL, ...) clobbers %r7 register on s390{,x}
https://sourceware.org/bugzilla/show_bug.cgi?id=31402
- glibc-commit on master:
S390: Do not clobber r7 in clone [BZ #31402]
https://sourceware.org/git/?p=glibc.git;a=commit;h=02782fd12849b6673cb5c2728cb750e8ec295aa3
- glibc-commit on release/2.37/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=9a1bdd7df731a4bc60f72dbdc1b849e02cfa9c34
- glibc-commit on release/2.38/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=ee4806e978467d705b26ccb7dfddb9e0a710f8e4
- glibc-commit on release/2.39/master:
https://sourceware.org/git/?p=glibc.git;a=commit;h=e0910f1d3278f05439fb434ee528fc9be1b6bd5e
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2055175/+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 1983223] Re: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu part
*** This bug is a duplicate of bug 2049703 *** https://bugs.launchpad.net/bugs/2049703 ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: ubuntu-z-systems Status: Confirmed => 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/1983223 Title: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu part Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Currently, KVM guests will see an evenly distributed CPU topology, where every CPU resides on a separate drawer. This may not be optimal for scheduling decisions. The goal of this feature is to allow to specify a virtual CPU topology which can help to configure the guest for better performance. The full range of topology nodes should be configurable (drawer -> book -> chip -> core -> thread). This feature has a kernel, qemu and libvirt part. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1983223/+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 2027926] Re: [24.04 FEAT] [VS2308] KVM: Implement counters for nested guest shadow events
** 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/2027926 Title: [24.04 FEAT] [VS2308] KVM: Implement counters for nested guest shadow events Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: Guest-3 memory needs to be represented by shadow page tables in the Guest-1 hypervisor. These shadow tables are discarded in certain conditions and need to be rebuilt in consequence, which negatively impacts the nested guest's performance. KVM performance counters for the shadow/unshadow events can help to diagnose performance issues. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2027926/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
This issue is s390-specific only, and does not affect aws at all. Hence adding tag verification-done again to potentially unblock the process. ** Tags removed: verification-needed-jammy-linux-aws-6.5 verification-needed-jammy-linux-gcp-6.5 verification-needed-mantic-linux-azure ** Tags added: verification-done verification-done-jammy-linux-aws-6.5 verification-done-jammy-linux-gcp-6.5 verification-done-mantic-linux-azure -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
This issue is s390x only, and not related to aws at all. Hence adding verification-done again to potentially unblock the process. ** Tags removed: verification-needed-jammy-linux-aws-6.5 verification-needed-jammy-linux-gcp-6.5 verification-needed-mantic-linux-azure ** Tags added: verification-done verification-done-jammy-linux-aws-6.5 verification-done-jammy-linux-gcp-6.5 verification-done-mantic-linux-azure -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
This issue is s390-specific only, and does not affect azure at all. Hence adding tag verification-done again to potentially unblock the process. ** Tags added: verification-done -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic,
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
This issue is s390x only, and not related to azure at all. Hence adding verification-done again to potentially unblock the process. ** Tags added: verification-done -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2052696] Re: [UBUNTU 24.04] Haskell LLVM Backend: Objects of data section are missing alignment
Hi Simon, no, it's of course not. The LP bug is pretty new (came in today) and I didn't had a chance to properly triage it. Will do it right now ... ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Status: New => Triaged ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ghc (Ubuntu) Status: New => Triaged ** Tags added: noble -- 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/2052696 Title: [UBUNTU 24.04] Haskell LLVM Backend: Objects of data section are missing alignment Status in Ubuntu on IBM z Systems: Triaged Status in ghc package in Ubuntu: Triaged Bug description: Description: Objects of the data section may be accessed through tagged pointers. Thus, those objects require a minimal alignment of 8 byte on a 64-bit architecture. Otherwise, this may lead to undefined behavior. Solution: commit https://gitlab.haskell.org/ghc/ghc/-/commit/dfe1c3540e4b519b62b862b5966dfec5cae9ece1 This patch resolves the alignment issue for all targets utilizing the LLVM backend. The fix was backported by upstream for ghc release 9.6 and 9.8 but not for 9.4.x which has landed in Noble. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2052696/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
This is s390x-specific only and does not affect gcp. Hence I'm adjusting the tag to potentially unblock the process. ** Tags added: verification-done -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic, the kernel code did not
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** Tags added: verification-done -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
This is s390x specific only and does not impact gcp. -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 1983223] Re: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu part
*** This bug is a duplicate of bug 2049703 *** https://bugs.launchpad.net/bugs/2049703 ** This bug has been marked a duplicate of bug 2049703 [24.04 FEAT] [VS2212] KVM: Enhanced and dynamic CPU topology for KVM guests (qemu) -- 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/1983223 Title: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu part Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: Currently, KVM guests will see an evenly distributed CPU topology, where every CPU resides on a separate drawer. This may not be optimal for scheduling decisions. The goal of this feature is to allow to specify a virtual CPU topology which can help to configure the guest for better performance. The full range of topology nodes should be configurable (drawer -> book -> chip -> core -> thread). This feature has a kernel, qemu and libvirt part. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1983223/+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 1983223] Re: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu 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/1983223 Title: [24.04 FEAT] [VS2029] KVM: Provide virtual CPU topology to guests - qemu part Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: Currently, KVM guests will see an evenly distributed CPU topology, where every CPU resides on a separate drawer. This may not be optimal for scheduling decisions. The goal of this feature is to allow to specify a virtual CPU topology which can help to configure the guest for better performance. The full range of topology nodes should be configurable (drawer -> book -> chip -> core -> thread). This feature has a kernel, qemu and libvirt part. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1983223/+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 2042363] Re: AIX 7.3 NFS client frequently returns an EIO error to an application when reading or writing to a file that has been locked with fcntl() on a Ubuntu 20.04 NFSV4 ser
I did a screening of the traces, but couldn't really find suspicious entries. I'm now looking for a someone else's view and 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/2042363 Title: AIX 7.3 NFS client frequently returns an EIO error to an application when reading or writing to a file that has been locked with fcntl() on a Ubuntu 20.04 NFSV4 server Status in linux package in Ubuntu: New Bug description: ---Problem Description--- AIX 7.3 NFS client frequently returns an EIO error to an application when reading or writing to a file that has been locked with fcntl(). NFS server is Ubuntu 20.04.6 LTS, GNU/Linux 5.4.0-139-generic x86_64. The problem does not appear to affect other combinations of NFS client (including AIX 7.2) with this NFS server. The AIX team have indicated that the cause of the EIO is triggered by the NFS server returning a BAD_SEQID error which leads to the AIX NFS client incorrectly zeroing the stateid, which then leads to the NFS server returning a BAD_STATEID error and the NFS client then returns the EIO error. The AIX team would like to understand why the BAD_SEQID has been returned. ---uname output--- Linux duckseason 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type = VMware ESXi Server 7.0 4 x Intel(R) Xeon(R) Gold 6348H CPU @ 2.30GHz ---Steps to Reproduce--- We cannot offer a simple way to recreate the problem as it involves IBM MQ running on two primary machines (AIX) using the Ubuntu server for it's HA NFSv4 storage. However, we can provide any requested trace or dumps from any or all of the involved machines. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2042363/+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 2051730] [NEW] vmlinuz-6.5.0-15-generic allows only one monitor to display on dual monitor video card.
Public bug reported: My system works fine using vmlinuz-5.15.0-92-generic. When I run software update and the new kernel vmlinuz-6.5.0-15-generic is installed I no longer have a dual monitor system. This is the second time this has happened and I have to return to a prior kernel version to get the second monitor to work. I noticed that the prior version is using "GRAPHICS: Quadro 2000/PCIe/SSE2" found in the SETTINGS ABOUT information and the new kernel is using "GRAPHICS:llvmpipe (LLVM 15.0.7.256 bits)". Both kernels are using the NVIDIA driver metapackage from nvidia-driver-390(proprietary tested). ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-generic 6.5.0-15.15~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Jan 30 14:29:15 2024 InstallationDate: Installed on 2024-01-21 (8 days ago) InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316) SourcePackage: linux-signed-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2024-01-22 (8 days ago) ** Affects: linux-signed-hwe-6.5 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2051730 Title: vmlinuz-6.5.0-15-generic allows only one monitor to display on dual monitor video card. Status in linux-signed-hwe-6.5 package in Ubuntu: New Bug description: My system works fine using vmlinuz-5.15.0-92-generic. When I run software update and the new kernel vmlinuz-6.5.0-15-generic is installed I no longer have a dual monitor system. This is the second time this has happened and I have to return to a prior kernel version to get the second monitor to work. I noticed that the prior version is using "GRAPHICS: Quadro 2000/PCIe/SSE2" found in the SETTINGS ABOUT information and the new kernel is using "GRAPHICS:llvmpipe (LLVM 15.0.7.256 bits)". Both kernels are using the NVIDIA driver metapackage from nvidia-driver-390(proprietary tested). ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-15-generic 6.5.0-15.15~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-15.15~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Jan 30 14:29:15 2024 InstallationDate: Installed on 2024-01-21 (8 days ago) InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316) SourcePackage: linux-signed-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2024-01-22 (8 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.5/+bug/2051730/+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 2032136] Re: System reboot to BIOS boot menu
Using this reboot=acpi parameter does not work for me to resolve the issue at all. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-6.2 in Ubuntu. https://bugs.launchpad.net/bugs/2032136 Title: System reboot to BIOS boot menu Status in linux-signed-hwe-6.2 package in Ubuntu: Confirmed Bug description: Ever since update of Linux kernel to 6.2.0-26, this laptop (Lenovo Thinkpad T520) on reboot, goes to a boot loop directly to the BIOS Boot menu. On from there, still stuck in that loop. It displays an error message just before the BIOS Boot menu, but flashes by too fast to actually make out what is there. If it shutdown, and cold boot, it boots normally to the Grub2 Boot menu. There is a problem somewhere. This machine is ZFS-On-Root. Another User says he is having this same problem, but on an LVM2 install. The common denominator seems to be the update to Linux kernel 6.2.0-26. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.2.0-26-generic 6.2.0-26.26~22.04.1 ProcVersionSignature: Ubuntu 6.2.0-26.26~22.04.1-generic 6.2.13 Uname: Linux 6.2.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: GNOME Date: Sun Aug 20 14:14:56 2023 InstallationDate: Installed on 2021-09-23 (696 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) SourcePackage: linux-signed-hwe-6.2 UpgradeStatus: Upgraded to jammy on 2022-08-17 (368 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.2/+bug/2032136/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
This is already Fix Released for L and M. It's not set in noble's 6.6.0-14.14, but in 6.8.0-2.2. Hence leaving it as Fix Committed for noble until we are on 6.8. ** Changed in: linux (Ubuntu Lunar) Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu Mantic) 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It
[Kernel-packages] [Bug 2049924] Re: WireGuard broken on Noble ppc64el
** Also affects: ubuntu-power-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-power-systems
Assignee: (unassigned) => bugproxy (bugproxy)
** Tags added: noble ppc64el reverse-proxy-bugzilla
--
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/2049924
Title:
WireGuard broken on Noble ppc64el
Status in The Ubuntu-power-systems project:
New
Status in linux package in Ubuntu:
New
Status in netplan.io package in Ubuntu:
New
Status in linux source package in Noble:
New
Status in netplan.io source package in Noble:
New
Bug description:
Netplan autopkgtests related to Wireguard are currently failing (see
below) on Noble ppc64el. Trying it manually on a ppc64el system, I
can't load the kernel module:
~# modprobe wireguard
modprobe: ERROR: could not insert 'wireguard': No such device
And because of that the interface can't be created:
Jan 19 15:47:59 mantic-bos01-ppc64el NetworkManager[2414]:
[1705679279.5797] platform-linux: do-add-link[wg0/wireguard]: failure 95
(Operation not supported - Unknown device type)
Jan 19 15:47:59 mantic-bos01-ppc64el NetworkManager[2414]:
[1705679279.5797] manager: (netplan-wg0) couldn't create the device: Failed to
create WireGuard interface 'wg0' for 'netplan-wg0': Operation not supported
Jan 19 15:45:08 mantic-bos01-ppc64el systemd-networkd[731]:
/run/systemd/network/10-netplan-wg0.netdev has 0644 mode that is too
permissive, please adjust the ownership and access mode.
Jan 19 15:45:08 mantic-bos01-ppc64el systemd-networkd[731]: wg0: netdev could
not be created: Operation not supported
Autopkgtest error:
2690s .Interface "wg0" not found.
2691s .Interface "wg0" not found.
2692s .Interface "wg0" not found.
2693s ..Interface "wg0" not found.
2694s Interface "wg0" not found.
2695s .Interface "wg0" not found.
2696s .Interface "wg0" not found.
2697s .Interface "wg0" not found.
2697s FAIL
2697s
2697s ==
2697s FAIL: test_tunnel_wireguard
(__main__.TestNetworkManager.test_tunnel_wireguard)
2697s --
2697s Traceback (most recent call last):
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/tunnels.py", line 126,
in test_tunnel_wireguard
2697s self.generate_and_settle(['wg0', 'wg1'])
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 363, in
generate_and_settle
2697s self.nm_wait_connected(iface, 60)
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 419, in
nm_wait_connected
2697s self.wait_output(['nmcli', 'dev', 'show', iface], '(connected',
timeout)
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 416, in
wait_output
2697s self.fail('timed out waiting for "{}" to appear in
{}'.format(expected_output, cmd))
2697s AssertionError: timed out waiting for "(connected" to appear in
['nmcli', 'dev', 'show', 'wg0']
2697s
2697s ==
2697s FAIL: test_tunnel_wireguard
(__main__.TestNetworkd.test_tunnel_wireguard)
2697s --
2697s Traceback (most recent call last):
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/tunnels.py", line 126,
in test_tunnel_wireguard
2697s self.generate_and_settle(['wg0', 'wg1'])
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 365, in
generate_and_settle
2697s self.networkd_wait_connected(iface, 60)
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 423, in
networkd_wait_connected
2697s self.wait_output(['networkctl', 'status', iface], '(configured',
timeout)
2697s File
"/tmp/autopkgtest.N9l4Wi/build.nQ5/src/tests/integration/base.py", line 416, in
wait_output
2697s self.fail('timed out waiting for "{}" to appear in
{}'.format(expected_output, cmd))
2697s AssertionError: timed out waiting for "(configured" to appear in
['networkctl', 'status', 'wg0']
2697s
2697s --
2697s Ran 26 tests in 294.247s
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2049924/+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 2050017] Re: [24.04 FEAT] [SEC2339] HSM protected signing support for Apache httpd for openSSL 3.0 with PKCS #11 provider
** Information type changed from Private to Public ** Package changed: linux (Ubuntu) => apache2 (Ubuntu) -- 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/2050017 Title: [24.04 FEAT] [SEC2339] HSM protected signing support for Apache httpd for openSSL 3.0 with PKCS #11 provider Status in Ubuntu on IBM z Systems: New Status in apache2 package in Ubuntu: New Bug description: Enable an E2E use case that allows to configure an Apache webserver to protect its private keys with an HSM that is addressable via an PKCS #11 (signing) provider configured for an openSSL 3.0 library. Accepted for httpd > 2.4.58, see https://svn.apache.org/viewvc?view=revision=1914365 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2050017/+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 2049958] [NEW] package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to make backup link of './usr/lib/bluetooth/obexd' before installing new version: Input/output
Public bug reported:
bug found during software update launched from bootable usb
ProblemType: Package
DistroRelease: Ubuntu 23.10
Package: bluez-obexd 5.68-0ubuntu1
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckMismatches: ./casper/minimal.squashfs
CasperMD5CheckResult: fail
CasperVersion: 1.486
CloudArchitecture: x86_64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud)
Date: Sat Jan 20 00:18:32 2024
DuplicateSignature:
package:bluez-obexd:5.68-0ubuntu1
Unpacking bluez-obexd (5.68-0ubuntu1.1) over (5.68-0ubuntu1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MsVzUs/045-bluez-obexd_5.68-0ubuntu1.1_amd64.deb
(--unpack):
unable to make backup link of './usr/lib/bluetooth/obexd' before installing
new version: Input/output error
ErrorMessage: unable to make backup link of './usr/lib/bluetooth/obexd' before
installing new version: Input/output error
InterestingModules: rfcomm bnep btusb bluetooth
LiveMediaBuild: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz persistent
layerfs-path=minimal.standard.live.squashfs --- quiet splash
Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
PythonDetails: N/A
RelatedPackageVersions:
dpkg 1.22.0ubuntu1
apt 2.7.3
SourcePackage: bluez
Title: package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to
make backup link of './usr/lib/bluetooth/obexd' before installing new version:
Input/output error
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/26/2018
dmi.bios.release: 5.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 306
dmi.board.asset.tag: Default string
dmi.board.name: GL553VW
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr306:bd09/26/2018:br5.6:svnASUSTeKCOMPUTERINC.:pnGL553VW:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnGL553VW:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:skuASUS-NotebookSKU:
dmi.product.family: GL
dmi.product.name: GL553VW
dmi.product.sku: ASUS-NotebookSKU
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
hciconfig:
hci0: Type: Primary Bus: USB
BD Address: D0:57:7B:12:13:2F ACL MTU: 1021:5 SCO MTU: 96:6
UP RUNNING
RX bytes:1345 acl:0 sco:0 events:90 errors:0
TX bytes:3835 acl:0 sco:0 commands:90 errors:0
** Affects: bluez (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-package mantic need-duplicate-check
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/2049958
Title:
package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to
make backup link of './usr/lib/bluetooth/obexd' before installing new
version: Input/output error
Status in bluez package in Ubuntu:
New
Bug description:
bug found during software update launched from bootable usb
ProblemType: Package
DistroRelease: Ubuntu 23.10
Package: bluez-obexd 5.68-0ubuntu1
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckMismatches: ./casper/minimal.squashfs
CasperMD5CheckResult: fail
CasperVersion: 1.486
CloudArchitecture: x86_64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud)
Date: Sat Jan 20 00:18:32 2024
DuplicateSignature:
package:bluez-obexd:5.68-0ubuntu1
Unpacking bluez-obexd (5.68-0ubuntu1.1) over (5.68-0ubuntu1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MsVzUs/045-bluez-obexd_5.68-0ubuntu1.1_amd64.deb
(--unpack):
unable to make backup link of './usr/lib/bluetooth/obexd' before installing
new version: Input/output error
ErrorMessage: unable to make backup link of './usr/lib/bluetooth/obexd'
before installing new version: Input/output error
InterestingModules: rfcomm bnep btusb bluetooth
LiveMediaBuild: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz persistent
layerfs-path=minimal.standard.live.squashfs --- quiet splash
Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
PythonDetails: N/A
RelatedPackageVersions:
dpkg 1.22.0ubuntu1
apt 2.7.3
SourcePackage: bluez
Title: package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to
[Kernel-packages] [Bug 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
Thx Andreas for your +1 -- 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/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2049592] Re: [UBUNTU 22.04] createrepo_c not working under 22.04.3
** Package changed: linux (Ubuntu) => createrepo-c (Ubuntu) -- 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/2049592 Title: [UBUNTU 22.04] createrepo_c not working under 22.04.3 Status in createrepo-c package in Ubuntu: New Bug description: === Provided by Thorsten 2024-01-16 == We are running Ubuntu 22.04.3 on IBM Z. createrepo_c is not working and responds: createrepo_c: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory I seems that it is linked against openssl-1.1, but jammy provide openssl-3.0.2. Here is the output of ldd: ldd /usr/bin/createrepo_c linux-vdso64.so.1 (0x03ff85afe000) libcreaterepo_c.so.0 => /usr/local/lib/libcreaterepo_c.so.0 (0x03ff8590) libglib-2.0.so.0 => /lib/s390x-linux-gnu/libglib-2.0.so.0 (0x03ff8578) libmodulemd.so.2 => /usr/local/lib/libmodulemd.so.2 (0x03ff8570) libgobject-2.0.so.0 => /lib/s390x-linux-gnu/libgobject-2.0.so.0 (0x03ff8568) libc.so.6 => /lib/s390x-linux-gnu/libc.so.6 (0x03ff8548) libbz2.so.1.0 => /lib/s390x-linux-gnu/libbz2.so.1.0 (0x03ff8540) libcurl-gnutls.so.4 => /lib/s390x-linux-gnu/libcurl-gnutls.so.4 (0x03ff8530) libmagic.so.1 => /lib/s390x-linux-gnu/libmagic.so.1 (0x03ff8528) libxml2.so.2 => /lib/s390x-linux-gnu/libxml2.so.2 (0x03ff8508) liblzma.so.5 => /lib/s390x-linux-gnu/liblzma.so.5 (0x03ff8500) libcrypto.so.1.1 => not found librpm.so.8 => not found librpmio.so.8 => not found libsqlite3.so.0 => /lib/s390x-linux-gnu/libsqlite3.so.0 (0x03ff84e8) libz.so.1 => /lib/s390x-linux-gnu/libz.so.1 (0x03ff84e0) libzck.so.1 => /usr/local/lib/libzck.so.1 (0x03ff84d8) libpcre.so.3 => /lib/s390x-linux-gnu/libpcre.so.3 (0x03ff84d0) libm.so.6 => /lib/s390x-linux-gnu/libm.so.6 (0x03ff84c0) librpmio.so.8 => not found libyaml-0.so.2 => /lib/s390x-linux-gnu/libyaml-0.so.2 (0x03ff84b8) libffi.so.8 => /lib/s390x-linux-gnu/libffi.so.8 (0x03ff84b0) /lib/ld64.so.1 (0x03ff85a8) libnghttp2.so.14 => /lib/s390x-linux-gnu/libnghttp2.so.14 (0x03ff84a8) libidn2.so.0 => /lib/s390x-linux-gnu/libidn2.so.0 (0x03ff84a0) librtmp.so.1 => /lib/s390x-linux-gnu/librtmp.so.1 (0x03ff8498) libssh.so.4 => /lib/s390x-linux-gnu/libssh.so.4 (0x03ff8490) libpsl.so.5 => /lib/s390x-linux-gnu/libpsl.so.5 (0x03ff8488) libnettle.so.8 => /lib/s390x-linux-gnu/libnettle.so.8 (0x03ff8480) libgnutls.so.30 => /lib/s390x-linux-gnu/libgnutls.so.30 (0x03ff8460) libgssapi_krb5.so.2 => /lib/s390x-linux-gnu/libgssapi_krb5.so.2 (0x03ff8458) libldap-2.5.so.0 => /lib/s390x-linux-gnu/libldap-2.5.so.0 (0x03ff8450) liblber-2.5.so.0 => /lib/s390x-linux-gnu/liblber-2.5.so.0 (0x03ff8448) libzstd.so.1 => /lib/s390x-linux-gnu/libzstd.so.1 (0x03ff8438) libbrotlidec.so.1 => /lib/s390x-linux-gnu/libbrotlidec.so.1 (0x03ff8430) libicuuc.so.70 => /lib/s390x-linux-gnu/libicuuc.so.70 (0x03ff8408) libcrypto.so.1.1 => not found libunistring.so.2 => /lib/s390x-linux-gnu/libunistring.so.2 (0x03ff83e8) libhogweed.so.6 => /lib/s390x-linux-gnu/libhogweed.so.6 (0x03ff83e0) libgmp.so.10 => /lib/s390x-linux-gnu/libgmp.so.10 (0x03ff83d0) libcrypto.so.3 => /lib/s390x-linux-gnu/libcrypto.so.3 (0x03ff8390) libp11-kit.so.0 => /lib/s390x-linux-gnu/libp11-kit.so.0 (0x03ff8378) libtasn1.so.6 => /lib/s390x-linux-gnu/libtasn1.so.6 (0x03ff8370) libkrb5.so.3 => /lib/s390x-linux-gnu/libkrb5.so.3 (0x03ff8360) libk5crypto.so.3 => /lib/s390x-linux-gnu/libk5crypto.so.3 (0x03ff8358) libcom_err.so.2 => /lib/s390x-linux-gnu/libcom_err.so.2 (0x03ff8350) libkrb5support.so.0 => /lib/s390x-linux-gnu/libkrb5support.so.0 (0x03ff8348) libsasl2.so.2 => /lib/s390x-linux-gnu/libsasl2.so.2 (0x03ff8340) libbrotlicommon.so.1 => /lib/s390x-linux-gnu/libbrotlicommon.so.1 (0x03ff8338) libicudata.so.70 => /lib/s390x-linux-gnu/libicudata.so.70 (0x03ff8170) libstdc++.so.6 => /lib/s390x-linux-gnu/libstdc++.so.6 (0x03ff8148) libgcc_s.so.1 => /lib/s390x-linux-gnu/libgcc_s.so.1 (0x03ff8140) libkeyutils.so.1 => /lib/s390x-linux-gnu/libkeyutils.so.1 (0x03ff8138) libresolv.so.2 => /lib/s390x-linux-gnu/libresolv.so.2 (0x03ff8130)
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
Thx for the prompt verification! -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
Thanks for the verification @mjrosato ! ** Tags added: verification-done-lunar-linux verification-done-mantic- linux -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic, the kernel code did not require backporting due to the base
[Kernel-packages] [Bug 2038587] Re: Turning COMPAT_32BIT_TIME off on ppc64el
** Changed in: ubuntu-power-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2038587 Title: Turning COMPAT_32BIT_TIME off on ppc64el Status in The Ubuntu-power-systems project: Fix Committed Status in linux package in Ubuntu: Fix Committed Bug description: This will prevent existing 32-bit powerpcle binaries to operate correctly, if they are still using 32bit time. And even exists? 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2038587/+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 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic, the kernel code did not require backporting due to the base kernel version already containing it, but
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes
Thx for the hint, klebers - I missed that. With that I can also set the project entry to Fix Released and close this bug. ** 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/2039575 Title: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Released Bug description: SRU Justification: [Impact] * There is a wrong bucket calculation for payload of exactly 4096 bytes in SMC stats counters. * SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB have these issues. * The impact is that a system silently updates an incorrect stats counter in case the underlying kernel is not UBSAN enabled. (Difficult to detect.) * But if a kernel is UBSAN enabled, one will see a UBSAN 'array-index-out-of-bounds' warning every time this occurs, like: [ 26.335381] UBSAN: array-index-out-of-bounds in /build/linux-O6Qi7m/linux-5.15.0/net/smc/af_smc.c:2402:3 [ 26.335385] index -1 is out of range for type 'u64 [9]' [ 26.335388] CPU: 0 PID: 274 Comm: iperf3 Tainted: G E 5.15.0-79-generic #86-Ubuntu [ 26.335391] Hardware name: IBM 8561 T01 772 (KVM/Linux) [ 26.335393] Call Trace: [ 26.335397] [] dump_stack_lvl+0x62/0x80 [ 26.335404] [ ] ubsan_epilogue+0x1c/0x48 [ 26.335406] [ ] __ubsan_handle_out_of_bounds+0x94/0xa0 [ 26.335411] [<03ff8033f9da>] smc_sendmsg+0x2aa/0x2d0 [smc] [ 26.335425] [ ] sock_sendmsg+0x64/0x80 [ 26.335431] [ ] sock_write_iter+0x72/0xa0 [ 26.335433] [ ] new_sync_write+0x100/0x190 [ 26.335438] [ ] vfs_write+0x1e8/0x280 [ 26.335440] [ ] ksys_write+0xb4/0x100 [ 26.335442] [ ] __do_syscall+0x1bc/0x1f0 [ 26.335446] [ ] system_call+0x78/0xa0 [Fix] * a950a5921db4 a950a5921db450c74212327f69950ff03419483a "net/smc: Fix pos miscalculation in statistics" [Test Plan] * Since this got identified while the livepatch for jammy patches got added, one could run a simiar (or the same) test like mentioned at LP#1639924 (but only jammy comes with official livepatch support). * Alternatively a dedicated SMC stats counters test with a payload of exactly 4096 bytes could be done (which is probably easier): * Install uperf (https://uperf.org/ - https://github.com/uperf/uperf). (Wondering if it makes sense to pick this up as Debian/Ubuntu package ?!) * Reset SMC-D stats on client and server side. * Start uperf at the server side using: # uperf -vs * Update profile with remote IP (server IP) and start uperf at client: # uperf -vai 5 -m rr1c-4kx4k---1.xml with uperf profile: # cat rr1c-4kx4k---1.xml * The smcd stats output is: # smcd -d stats reset SMC-D Connections Summary Total connections handled 2 SMC connections 2 (client 2, server 0) v1 0 v2 2 Handshake errors 0 (client 0, server 0) Avg requests per SMC conn 14.0 TCP fallback 0 (client 0, server 0) RX Stats Data transmitted (Bytes) 5796 (5.796K) Total requests 9 Buffer full 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 0 0 2 0 0 0 1 Reqs 8 0 0 0 0 0 0 0 TX Stats Data transmitted (Bytes) 9960 (9.960K) Total requests 19 Buffer full 0 (0.00%) Buffer full (remote) 0 (0.00%) Buffer too small 0 (0.00%) Buffer too small (remote) 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 2 0 0 0 0 0 0 Reqs 18 0 0 0 0 0 0 1 Extras Special socket calls 0 cork 0 nodelay 0 sendpage 0 splice 0 urgent data 0 * Instead of including the payload in the wrong >512 KB buckets, the output should be to have 19 reqs in the 8 KB buckets for TX stats and 9 reqs in the 8 KB bucket for RX stats. [Where problems could occur] * The changes are in common code /net/smc/smc_stats.h hence any potential negativ impact is not limited to a specific platform. but limited to statistics for shared memory communication (SMC) hardware statistics. * But limited to the
[Kernel-packages] [Bug 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: In Progress Status in linux source package in Noble: In Progress Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
Thanks Steffen for raising this and bringing this to our attention. That should obviously not have happen, kernel config changes should be propagated to all newer Ubuntu kernel version, until explicitly dropped or modified for any other reason. It looks like we hit a kind of a race condition here. While setting this option in jammy, the development of mantic just started and it was missed to enable it in the 'unstable' tree at that time. We are looking into it soon-ish. I believe that having a kernel in PPA to unblock you is not very helpful, since I think you need that kernel signed with the usual (prod.) signature/key (and not with a test/dev key coming from the PPA). Since lunar will reach it's eol in less than 2 weeks, we'll ensure that the option is set in mantic onwards. -- 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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** Changed in: linux (Ubuntu Lunar) Status: New => Won't Fix ** Changed in: linux (Ubuntu Noble) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-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/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2048919 Title: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Status in linux source package in Lunar: Won't Fix Status in linux source package in Mantic: New Status in linux source package in Noble: New Bug description: ---Problem Description--- Regression: uvdevice at /dev/uv not compiled into kernel Machine Type = IBM z15, IBM z16 Contact Information = steffen.ei...@ibm.com ---uname output--- Linux 6.5.0-14-generic #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 s390x s390x s390x GNU/Linux ---Debugger--- A debugger is not configured ---Additional Hardware Info--- Secure Execution feature code enabled (optional) ---Steps to Reproduce--- # working/ old behavior on a fresh ubuntu 22.10 (and 22.04) LPAR/guest1 (with Secure execution available) > cat /dev/uv /dev/uv > cat /boot/config-$(uname -r) | grep UV_UAPI CONFIG_S390_UV_UAPI=y that's the expected state for Ubuntu. # current/ non expected behavior since Ubuntu 23.04 the following happens: stock kernel non-modified, latest available > cat /dev/uv cat: /dev/uv: No such file or directory COMMENT: this still can happen if the machine has no Secure Execution feature available However, the following should not be the case under any circumstances: > cat /boot/config-$(uname -r) | grep UV_UAPI # CONFIG_S390_UV_UAPI is not set Somehow that configuration got lost between 22.X and 23.X. Maybe, because IIRC that features got back-ported to 22.X # Proposed Solution: change the kernel config to CONFIG_S390_UV_UAPI=y(same as 22.X backport) or CONFIG_S390_UV_UAPI=m(same as upstream) and provide a new kernel binary Stack trace output: n/a System Dump Info: The system is not configured to capture a system dump. Oops output: n/a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2048919/+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 1878279] Re: MSFT0004:00 06CB:CD98 Touchpad/trackpad mouse randomly not recognized from any given boot
Few hours after posting I got the 6.5.0-14-generic update. So I'll test it out for a while and see if the issue persists or if it's fixed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe in Ubuntu. https://bugs.launchpad.net/bugs/1878279 Title: MSFT0004:00 06CB:CD98 Touchpad/trackpad mouse randomly not recognized from any given boot Status in Linux: Confirmed Status in Ubuntu: Confirmed Status in linux-signed-hwe package in Ubuntu: In Progress Status in linux-signed-hwe package in Fedora: New Bug description: Touchpad 'Buttonless Mylar surface multi-touch touchpad' doesn't work at all (No response from the Touchpad) for notebook 'Lenovo Ideapad 5 14IIL05 81YH' from first system start on. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-29-generic 5.4.0-29.33 ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30 Uname: Linux 5.4.0-29-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: tilman 1607 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 12 21:22:22 2020 InstallationDate: Installed on 2020-05-12 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 81YH ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic root=UUID=bb961a96-8855-4e50-814d-7994235377c3 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.4.0-29-generic N/A linux-backports-modules-5.4.0-29-generic N/A linux-firmware1.187 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/25/2020 dmi.bios.vendor: LENOVO dmi.bios.version: DSCN23WW(V1.09) dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: No DPK dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: IdeaPad 5 14IIL05 dmi.modalias: dmi:bvnLENOVO:bvrDSCN23WW(V1.09):bd03/25/2020:svnLENOVO:pn81YH:pvrIdeaPad514IIL05:rvnLENOVO:rnLNVNB161216:rvrNoDPK:cvnLENOVO:ct10:cvrIdeaPad514IIL05: dmi.product.family: IdeaPad 5 14IIL05 dmi.product.name: 81YH dmi.product.sku: LENOVO_MT_81YH_BU_idea_FM_IdeaPad 5 14IIL05 dmi.product.version: IdeaPad 5 14IIL05 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1878279/+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 1878279] Re: MSFT0004:00 06CB:CD98 Touchpad/trackpad mouse randomly not recognized from any given boot
I'm on 6.2.0-39-generic (Ubuntu 22.04) and have started to get touchpad problems(I believe around September 2023). Touchpad often stops responding after having the laptop(Lenovo Yoga slim 14ARE05) on for a while. A full shutdown + waiting for a while and starting the laptop again makes the touchpad work again but just a reboot doesn't fix it. Don't think it will help but here are my journalctl logs from yesterday: jan 09 23:18:33 codingthing kernel: i2c_designware AMDI0010:00: controller timed out jan 09 23:18:32 codingthing kernel: i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration I didn't have this in the first 2 years of usage though. I'm unsure how to safely try other kernel versions myself so I'm really hoping this fix finds its way to Ubuntu 22.04 or 24.04 releases. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe in Ubuntu. https://bugs.launchpad.net/bugs/1878279 Title: MSFT0004:00 06CB:CD98 Touchpad/trackpad mouse randomly not recognized from any given boot Status in Linux: Confirmed Status in Ubuntu: Confirmed Status in linux-signed-hwe package in Ubuntu: In Progress Status in linux-signed-hwe package in Fedora: New Bug description: Touchpad 'Buttonless Mylar surface multi-touch touchpad' doesn't work at all (No response from the Touchpad) for notebook 'Lenovo Ideapad 5 14IIL05 81YH' from first system start on. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-29-generic 5.4.0-29.33 ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30 Uname: Linux 5.4.0-29-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: tilman 1607 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue May 12 21:22:22 2020 InstallationDate: Installed on 2020-05-12 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 81YH ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic root=UUID=bb961a96-8855-4e50-814d-7994235377c3 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.4.0-29-generic N/A linux-backports-modules-5.4.0-29-generic N/A linux-firmware1.187 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/25/2020 dmi.bios.vendor: LENOVO dmi.bios.version: DSCN23WW(V1.09) dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: No DPK dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: IdeaPad 5 14IIL05 dmi.modalias: dmi:bvnLENOVO:bvrDSCN23WW(V1.09):bd03/25/2020:svnLENOVO:pn81YH:pvrIdeaPad514IIL05:rvnLENOVO:rnLNVNB161216:rvrNoDPK:cvnLENOVO:ct10:cvrIdeaPad514IIL05: dmi.product.family: IdeaPad 5 14IIL05 dmi.product.name: 81YH dmi.product.sku: LENOVO_MT_81YH_BU_idea_FM_IdeaPad 5 14IIL05 dmi.product.version: IdeaPad 5 14IIL05 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1878279/+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 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
Makes sense to me - I'm +1 for turning it off starting with noble. -- 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/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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 2046439] Re: Wrong code execution of s390x code with qemu TCG
** Package changed: linux (Ubuntu) => qemu (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: qemu (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Status: New => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2046439 Title: Wrong code execution of s390x code with qemu TCG Status in Ubuntu on IBM z Systems: Triaged Status in qemu package in Ubuntu: New Bug description: ---Problem Description--- Wrong code execution with qemu ---Steps to Reproduce--- please have a look at the following bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986 Contact Information = Andreas Krebbel Machine Type = IBM Z Userspace tool common name: qemu The userspace tool has the following bit modes: 64 bit Userspace deb: - 1:6.2+dfsg-2ubuntu6.15 Frequently used s390x code sequences are wrongly executed when running with qemu instruction set emulation. The problem has been fixed in upstream qemu already. A backport for qemu 7 branch has been committed as well. The qemu 6.2.0 version used in Ubuntu 22.04 needs a backport of a trivial fix to work properly: From the GCC BZ: Problem fixed in v8.0.0 (https://gitlab.com/qemu-project/qemu/-/commit/54fce97cfcaf5463ee5f325bc1f1d4adc2772f38). The fix was backported to v7.2.2 (https://gitlab.com/qemu-project/qemu/-/commit/17b032c6598ea756889f25e8d3e4cd9f2036669b), but not to v6. Please consider picking up https://gitlab.com/qemu-project/qemu/-/commit/17b032c6598ea756889f25e8d3e4cd9f2036669b for the Ubuntu 22.04 qemu package 1:6.2+dfsg-2ubuntu6.15 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2046439/+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 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes
** Changed in: linux (Ubuntu) Status: New => 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/2039575 Title: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Released Status in linux source package in Mantic: Fix Committed Bug description: SRU Justification: [Impact] * There is a wrong bucket calculation for payload of exactly 4096 bytes in SMC stats counters. * SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB have these issues. * The impact is that a system silently updates an incorrect stats counter in case the underlying kernel is not UBSAN enabled. (Difficult to detect.) * But if a kernel is UBSAN enabled, one will see a UBSAN 'array-index-out-of-bounds' warning every time this occurs, like: [ 26.335381] UBSAN: array-index-out-of-bounds in /build/linux-O6Qi7m/linux-5.15.0/net/smc/af_smc.c:2402:3 [ 26.335385] index -1 is out of range for type 'u64 [9]' [ 26.335388] CPU: 0 PID: 274 Comm: iperf3 Tainted: G E 5.15.0-79-generic #86-Ubuntu [ 26.335391] Hardware name: IBM 8561 T01 772 (KVM/Linux) [ 26.335393] Call Trace: [ 26.335397] [] dump_stack_lvl+0x62/0x80 [ 26.335404] [ ] ubsan_epilogue+0x1c/0x48 [ 26.335406] [ ] __ubsan_handle_out_of_bounds+0x94/0xa0 [ 26.335411] [<03ff8033f9da>] smc_sendmsg+0x2aa/0x2d0 [smc] [ 26.335425] [ ] sock_sendmsg+0x64/0x80 [ 26.335431] [ ] sock_write_iter+0x72/0xa0 [ 26.335433] [ ] new_sync_write+0x100/0x190 [ 26.335438] [ ] vfs_write+0x1e8/0x280 [ 26.335440] [ ] ksys_write+0xb4/0x100 [ 26.335442] [ ] __do_syscall+0x1bc/0x1f0 [ 26.335446] [ ] system_call+0x78/0xa0 [Fix] * a950a5921db4 a950a5921db450c74212327f69950ff03419483a "net/smc: Fix pos miscalculation in statistics" [Test Plan] * Since this got identified while the livepatch for jammy patches got added, one could run a simiar (or the same) test like mentioned at LP#1639924 (but only jammy comes with official livepatch support). * Alternatively a dedicated SMC stats counters test with a payload of exactly 4096 bytes could be done (which is probably easier): * Install uperf (https://uperf.org/ - https://github.com/uperf/uperf). (Wondering if it makes sense to pick this up as Debian/Ubuntu package ?!) * Reset SMC-D stats on client and server side. * Start uperf at the server side using: # uperf -vs * Update profile with remote IP (server IP) and start uperf at client: # uperf -vai 5 -m rr1c-4kx4k---1.xml with uperf profile: # cat rr1c-4kx4k---1.xml * The smcd stats output is: # smcd -d stats reset SMC-D Connections Summary Total connections handled 2 SMC connections 2 (client 2, server 0) v1 0 v2 2 Handshake errors 0 (client 0, server 0) Avg requests per SMC conn 14.0 TCP fallback 0 (client 0, server 0) RX Stats Data transmitted (Bytes) 5796 (5.796K) Total requests 9 Buffer full 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 0 0 2 0 0 0 1 Reqs 8 0 0 0 0 0 0 0 TX Stats Data transmitted (Bytes) 9960 (9.960K) Total requests 19 Buffer full 0 (0.00%) Buffer full (remote) 0 (0.00%) Buffer too small 0 (0.00%) Buffer too small (remote) 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 2 0 0 0 0 0 0 Reqs 18 0 0 0 0 0 0 1 Extras Special socket calls 0 cork 0 nodelay 0 sendpage 0 splice 0 urgent data 0 * Instead of including the payload in the wrong >512 KB buckets, the output should be to have 19 reqs in the 8 KB buckets for TX stats and 9 reqs in the 8 KB bucket for RX stats. [Where problems could occur] * The changes are in common code /net/smc/smc_stats.h hence any potential negativ impact is not limited to a specific platform. but limited to statistics for shared memory communication (SMC) hardware statistics. * But limited to the functions SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB. * The bucket (aka pos) calculation is not that trivial, issues here
[Kernel-packages] [Bug 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes
affects linux-generic only ** Tags removed: verification-needed-focal-linux-gcp-tcpx ** Tags added: verification-done-focal-linux-gcp-tcpx -- 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/2039575 Title: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: New Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux source package in Mantic: Fix Committed Bug description: SRU Justification: [Impact] * There is a wrong bucket calculation for payload of exactly 4096 bytes in SMC stats counters. * SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB have these issues. * The impact is that a system silently updates an incorrect stats counter in case the underlying kernel is not UBSAN enabled. (Difficult to detect.) * But if a kernel is UBSAN enabled, one will see a UBSAN 'array-index-out-of-bounds' warning every time this occurs, like: [ 26.335381] UBSAN: array-index-out-of-bounds in /build/linux-O6Qi7m/linux-5.15.0/net/smc/af_smc.c:2402:3 [ 26.335385] index -1 is out of range for type 'u64 [9]' [ 26.335388] CPU: 0 PID: 274 Comm: iperf3 Tainted: G E 5.15.0-79-generic #86-Ubuntu [ 26.335391] Hardware name: IBM 8561 T01 772 (KVM/Linux) [ 26.335393] Call Trace: [ 26.335397] [] dump_stack_lvl+0x62/0x80 [ 26.335404] [ ] ubsan_epilogue+0x1c/0x48 [ 26.335406] [ ] __ubsan_handle_out_of_bounds+0x94/0xa0 [ 26.335411] [<03ff8033f9da>] smc_sendmsg+0x2aa/0x2d0 [smc] [ 26.335425] [ ] sock_sendmsg+0x64/0x80 [ 26.335431] [ ] sock_write_iter+0x72/0xa0 [ 26.335433] [ ] new_sync_write+0x100/0x190 [ 26.335438] [ ] vfs_write+0x1e8/0x280 [ 26.335440] [ ] ksys_write+0xb4/0x100 [ 26.335442] [ ] __do_syscall+0x1bc/0x1f0 [ 26.335446] [ ] system_call+0x78/0xa0 [Fix] * a950a5921db4 a950a5921db450c74212327f69950ff03419483a "net/smc: Fix pos miscalculation in statistics" [Test Plan] * Since this got identified while the livepatch for jammy patches got added, one could run a simiar (or the same) test like mentioned at LP#1639924 (but only jammy comes with official livepatch support). * Alternatively a dedicated SMC stats counters test with a payload of exactly 4096 bytes could be done (which is probably easier): * Install uperf (https://uperf.org/ - https://github.com/uperf/uperf). (Wondering if it makes sense to pick this up as Debian/Ubuntu package ?!) * Reset SMC-D stats on client and server side. * Start uperf at the server side using: # uperf -vs * Update profile with remote IP (server IP) and start uperf at client: # uperf -vai 5 -m rr1c-4kx4k---1.xml with uperf profile: # cat rr1c-4kx4k---1.xml * The smcd stats output is: # smcd -d stats reset SMC-D Connections Summary Total connections handled 2 SMC connections 2 (client 2, server 0) v1 0 v2 2 Handshake errors 0 (client 0, server 0) Avg requests per SMC conn 14.0 TCP fallback 0 (client 0, server 0) RX Stats Data transmitted (Bytes) 5796 (5.796K) Total requests 9 Buffer full 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 0 0 2 0 0 0 1 Reqs 8 0 0 0 0 0 0 0 TX Stats Data transmitted (Bytes) 9960 (9.960K) Total requests 19 Buffer full 0 (0.00%) Buffer full (remote) 0 (0.00%) Buffer too small 0 (0.00%) Buffer too small (remote) 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 2 0 0 0 0 0 0 Reqs 18 0 0 0 0 0 0 1 Extras Special socket calls 0 cork 0 nodelay 0 sendpage 0 splice 0 urgent data 0 * Instead of including the payload in the wrong >512 KB buckets, the output should be to have 19 reqs in the 8 KB buckets for TX stats and 9 reqs in the 8 KB bucket for RX stats. [Where problems could occur] * The changes are in common code /net/smc/smc_stats.h hence any potential negativ impact is not limited to a specific platform. but limited to statistics for shared memory communication (SMC) hardware statistics. * But limited to the functions SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB.
[Kernel-packages] [Bug 2038587] Re: Turning COMPAT_32BIT_TIME off on ppc64el
Just to close the loop: https://lore.kernel.org/all/20231124082512.gw9...@kitsune.suse.cz/T/#m64b790e83ff7d7b3e7df5baa239fb23ab907daa7 -- 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/2038587 Title: Turning COMPAT_32BIT_TIME off on ppc64el Status in The Ubuntu-power-systems project: In Progress Status in linux package in Ubuntu: In Progress Bug description: This will prevent existing 32-bit powerpcle binaries to operate correctly, if they are still using 32bit time. And even exists? 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2038587/+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 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes
** Tags removed: verification-done ** Tags added: verification-done-jammy-linux verification-done-lunar-linux verification-done-mantic-linux -- 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/2039575 Title: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: New Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux source package in Mantic: Fix Committed Bug description: SRU Justification: [Impact] * There is a wrong bucket calculation for payload of exactly 4096 bytes in SMC stats counters. * SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB have these issues. * The impact is that a system silently updates an incorrect stats counter in case the underlying kernel is not UBSAN enabled. (Difficult to detect.) * But if a kernel is UBSAN enabled, one will see a UBSAN 'array-index-out-of-bounds' warning every time this occurs, like: [ 26.335381] UBSAN: array-index-out-of-bounds in /build/linux-O6Qi7m/linux-5.15.0/net/smc/af_smc.c:2402:3 [ 26.335385] index -1 is out of range for type 'u64 [9]' [ 26.335388] CPU: 0 PID: 274 Comm: iperf3 Tainted: G E 5.15.0-79-generic #86-Ubuntu [ 26.335391] Hardware name: IBM 8561 T01 772 (KVM/Linux) [ 26.335393] Call Trace: [ 26.335397] [] dump_stack_lvl+0x62/0x80 [ 26.335404] [ ] ubsan_epilogue+0x1c/0x48 [ 26.335406] [ ] __ubsan_handle_out_of_bounds+0x94/0xa0 [ 26.335411] [<03ff8033f9da>] smc_sendmsg+0x2aa/0x2d0 [smc] [ 26.335425] [ ] sock_sendmsg+0x64/0x80 [ 26.335431] [ ] sock_write_iter+0x72/0xa0 [ 26.335433] [ ] new_sync_write+0x100/0x190 [ 26.335438] [ ] vfs_write+0x1e8/0x280 [ 26.335440] [ ] ksys_write+0xb4/0x100 [ 26.335442] [ ] __do_syscall+0x1bc/0x1f0 [ 26.335446] [ ] system_call+0x78/0xa0 [Fix] * a950a5921db4 a950a5921db450c74212327f69950ff03419483a "net/smc: Fix pos miscalculation in statistics" [Test Plan] * Since this got identified while the livepatch for jammy patches got added, one could run a simiar (or the same) test like mentioned at LP#1639924 (but only jammy comes with official livepatch support). * Alternatively a dedicated SMC stats counters test with a payload of exactly 4096 bytes could be done (which is probably easier): * Install uperf (https://uperf.org/ - https://github.com/uperf/uperf). (Wondering if it makes sense to pick this up as Debian/Ubuntu package ?!) * Reset SMC-D stats on client and server side. * Start uperf at the server side using: # uperf -vs * Update profile with remote IP (server IP) and start uperf at client: # uperf -vai 5 -m rr1c-4kx4k---1.xml with uperf profile: # cat rr1c-4kx4k---1.xml * The smcd stats output is: # smcd -d stats reset SMC-D Connections Summary Total connections handled 2 SMC connections 2 (client 2, server 0) v1 0 v2 2 Handshake errors 0 (client 0, server 0) Avg requests per SMC conn 14.0 TCP fallback 0 (client 0, server 0) RX Stats Data transmitted (Bytes) 5796 (5.796K) Total requests 9 Buffer full 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 0 0 2 0 0 0 1 Reqs 8 0 0 0 0 0 0 0 TX Stats Data transmitted (Bytes) 9960 (9.960K) Total requests 19 Buffer full 0 (0.00%) Buffer full (remote) 0 (0.00%) Buffer too small 0 (0.00%) Buffer too small (remote) 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 2 0 0 0 0 0 0 Reqs 18 0 0 0 0 0 0 1 Extras Special socket calls 0 cork 0 nodelay 0 sendpage 0 splice 0 urgent data 0 * Instead of including the payload in the wrong >512 KB buckets, the output should be to have 19 reqs in the 8 KB buckets for TX stats and 9 reqs in the 8 KB bucket for RX stats. [Where problems could occur] * The changes are in common code /net/smc/smc_stats.h hence any potential negativ impact is not limited to a specific platform. but limited to statistics for shared memory communication (SMC) hardware statistics. * But limited to the functions SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB.
[Kernel-packages] [Bug 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes
Thx @Boris and @Wenjia - I'll update the tags accordingly ... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2039575 Title: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: New Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Status in linux source package in Mantic: Fix Committed Bug description: SRU Justification: [Impact] * There is a wrong bucket calculation for payload of exactly 4096 bytes in SMC stats counters. * SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB have these issues. * The impact is that a system silently updates an incorrect stats counter in case the underlying kernel is not UBSAN enabled. (Difficult to detect.) * But if a kernel is UBSAN enabled, one will see a UBSAN 'array-index-out-of-bounds' warning every time this occurs, like: [ 26.335381] UBSAN: array-index-out-of-bounds in /build/linux-O6Qi7m/linux-5.15.0/net/smc/af_smc.c:2402:3 [ 26.335385] index -1 is out of range for type 'u64 [9]' [ 26.335388] CPU: 0 PID: 274 Comm: iperf3 Tainted: G E 5.15.0-79-generic #86-Ubuntu [ 26.335391] Hardware name: IBM 8561 T01 772 (KVM/Linux) [ 26.335393] Call Trace: [ 26.335397] [] dump_stack_lvl+0x62/0x80 [ 26.335404] [ ] ubsan_epilogue+0x1c/0x48 [ 26.335406] [ ] __ubsan_handle_out_of_bounds+0x94/0xa0 [ 26.335411] [<03ff8033f9da>] smc_sendmsg+0x2aa/0x2d0 [smc] [ 26.335425] [ ] sock_sendmsg+0x64/0x80 [ 26.335431] [ ] sock_write_iter+0x72/0xa0 [ 26.335433] [ ] new_sync_write+0x100/0x190 [ 26.335438] [ ] vfs_write+0x1e8/0x280 [ 26.335440] [ ] ksys_write+0xb4/0x100 [ 26.335442] [ ] __do_syscall+0x1bc/0x1f0 [ 26.335446] [ ] system_call+0x78/0xa0 [Fix] * a950a5921db4 a950a5921db450c74212327f69950ff03419483a "net/smc: Fix pos miscalculation in statistics" [Test Plan] * Since this got identified while the livepatch for jammy patches got added, one could run a simiar (or the same) test like mentioned at LP#1639924 (but only jammy comes with official livepatch support). * Alternatively a dedicated SMC stats counters test with a payload of exactly 4096 bytes could be done (which is probably easier): * Install uperf (https://uperf.org/ - https://github.com/uperf/uperf). (Wondering if it makes sense to pick this up as Debian/Ubuntu package ?!) * Reset SMC-D stats on client and server side. * Start uperf at the server side using: # uperf -vs * Update profile with remote IP (server IP) and start uperf at client: # uperf -vai 5 -m rr1c-4kx4k---1.xml with uperf profile: # cat rr1c-4kx4k---1.xml * The smcd stats output is: # smcd -d stats reset SMC-D Connections Summary Total connections handled 2 SMC connections 2 (client 2, server 0) v1 0 v2 2 Handshake errors 0 (client 0, server 0) Avg requests per SMC conn 14.0 TCP fallback 0 (client 0, server 0) RX Stats Data transmitted (Bytes) 5796 (5.796K) Total requests 9 Buffer full 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 0 0 2 0 0 0 1 Reqs 8 0 0 0 0 0 0 0 TX Stats Data transmitted (Bytes) 9960 (9.960K) Total requests 19 Buffer full 0 (0.00%) Buffer full (remote) 0 (0.00%) Buffer too small 0 (0.00%) Buffer too small (remote) 0 (0.00%) Buffer downgrades 0 Buffer reuses 0 8KB 16KB 32KB 64KB 128KB 256KB 512KB >512KB Bufs 0 2 0 0 0 0 0 0 Reqs 18 0 0 0 0 0 0 1 Extras Special socket calls 0 cork 0 nodelay 0 sendpage 0 splice 0 urgent data 0 * Instead of including the payload in the wrong >512 KB buckets, the output should be to have 19 reqs in the 8 KB buckets for TX stats and 9 reqs in the 8 KB bucket for RX stats. [Where problems could occur] * The changes are in common code /net/smc/smc_stats.h hence any potential negativ impact is not limited to a specific platform. but limited to statistics for shared memory communication (SMC) hardware statistics. * But limited to the functions SMC_STAT_PAYLOAD_SUB and SMC_STAT_RMB_SIZE_SUB. * The bucket (aka pos) calculation is not that trivial, issues here
[Kernel-packages] [Bug 2042677] Re: [UBUNTU 23.04] PKCS#11 Applications fail to find libopencryptoki.so library due to missing /etc/ld.so.conf.d entry.
Well, if I'm not mistaken this was discussed in LP#2022088, comment #4: https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/2022088/comments/4 And based on this, the quilt patch debian/patches/03-dlopen-soname.patch got expanded. How does your 'ec_tests -slot 0' output look like? My attempt: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 23.04 Release:23.04 Codename: lunar $ apt-cache policy opencryptoki libopencryptoki0 libopencryptoki-dev opencryptoki: Installed: 3.20.0+dfsg-0ubuntu1.1 Candidate: 3.20.0+dfsg-0ubuntu1.1 Version table: *** 3.20.0+dfsg-0ubuntu1.1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar-updates/universe s390x Packages 100 /var/lib/dpkg/status 3.20.0+dfsg-0ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar/universe s390x Packages libopencryptoki0: Installed: 3.20.0+dfsg-0ubuntu1.1 Candidate: 3.20.0+dfsg-0ubuntu1.1 Version table: *** 3.20.0+dfsg-0ubuntu1.1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar-updates/universe s390x Packages 100 /var/lib/dpkg/status 3.20.0+dfsg-0ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar/universe s390x Packages libopencryptoki-dev: Installed: 3.20.0+dfsg-0ubuntu1.1 Candidate: 3.20.0+dfsg-0ubuntu1.1 Version table: *** 3.20.0+dfsg-0ubuntu1.1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar-updates/universe s390x Packages 100 /var/lib/dpkg/status 3.20.0+dfsg-0ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports lunar/universe s390x Packages # sudo vi /etc/apt/sources.list # enable deb-src for universe and universe-updates $ sudo apt update && sudo apt full-upgrade $ sudo apt-get --yes build-dep opencryptoki $ sudo apt --yes install automake libtool m4 autoconf flex bison libcap-dev expect # libudev-dev $ git clone https://github.com/opencryptoki/opencryptoki $ cd opencryptoki $ sudo -i $ ./bootstrap.sh $ ./configure --enable-testcases $ make $ sudo ./testcases/crypto/ec_tests -slot 0 Using slot #0... With option: no_init: 0 -- * TESTCASE run_GenerateECCKeyPairSignVerify BEGIN Starting ECC generate key pair with pkey=0 ... * TESTCASE run_GenerateECCKeyPairSignVerify ERROR (testcases/crypto/ec_func.c:1538)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT -- * TESTCASE run_ImportECCKeyPairSignVerify BEGIN Starting ECC import key pair with pkey=0 ... * TESTCASE run_ImportECCKeyPairSignVerify ERROR (testcases/crypto/ec_func.c:1684)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT -- * TESTCASE run_TransferECCKeyPairSignVerify BEGIN Starting ECC transfer key pair with pkey=0 ... * TESTCASE run_TransferECCKeyPairSignVerify ERROR (testcases/crypto/ec_func.c:1854)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT -- * TESTCASE run_DeriveECDHKey BEGIN starting run_DeriveECDHKey with pkey=0 ... * TESTCASE run_DeriveECDHKey ERROR (testcases/crypto/ec_func.c:391)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT -- * TESTCASE run_DeriveECDHKeyKAT BEGIN starting run_DeriveECDHKeyKAT with pkey=0 ... * TESTCASE run_DeriveECDHKeyKAT ERROR (testcases/crypto/ec_func.c:925)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT -- * TESTSUITE run_DeriveBTC BEGIN starting run_DeriveBTC with pkey=0 ... * TESTCASE run_DeriveBTC ERROR (testcases/crypto/ec_func.c:2492)) C_OpenSession() rc = CKR_TOKEN_NOT_PRESENT Total=0, Ran=0, Passed=0, Failed=0, Skipped=0, Errors=6 (total elapsed time 0s 196us) Well, errors, but no obvious crash. syslog shows: 2023-11-27T15:03:07.490186+00:00 hwe0002 ec_tests: usr/lib/cca_stdll/cca_specific.c token_specific_init: Error loading library: 'libcsulcca.so' [libcsulcca.so: cannot open shared object file: No such file or directory] 2023-11-27T15:03:08.046466+00:00 hwe0002 ec_tests: usr/lib/ep11_stdll/ep11_specific.c ep11_load_host_lib: Error loading shared library 'libep11.so[.4][.3|.2|.1]' [libep11.so: cannot open shared object file: No such file or directory] But that is because I have no libcsulcca.so, nor libep11 installed ... Installing csulcca gets me along the first msg. But right now I don't have a new enough libep11 - the latest I have still wants libssl1.0.0 or libssl1.1. What is the exact output that you get? Where do you see the error - in the terminal where you call ec_tests or in the logs? (Btw. same output for mantic and jammy). ** Package changed: linux (Ubuntu) => opencryptoki (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-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/2042677 Title: [UBUNTU 23.04] PKCS#11 Applications fail to find libopencryptoki.so library due to missing /etc/ld.so.conf.d entry. Status in Ubuntu on IBM z Systems: New Status in
[Kernel-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu) ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding udev rule not
[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough
resend updated version: https://lists.ubuntu.com/archives/kernel-team/2023-November/thread.html#147088 -- 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/2042853 Title: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Lunar: In Progress Status in linux source package in Mantic: In Progress Status in linux source package in Noble: In Progress Bug description: SRU Justification: [Impact] * Today no s390x-specific vfio-pci devices (zPCI) can be passed from a KVM host to a KVM guest (incl. secure execution guests in the context of confidential computing). * s390x PCI passthrough needs various changes in the s390x kernel zPCI code (incl. the new s390x-specific Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0 and got backported to 22.04/jammy as part of LP: #1853306. * Lunar an newer Ubuntu releases have the code already included from upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the config option is not set, hence zPCI pass-through is still not possible. [Fix] * To be able to make use of VFIO zPCI pass-through on s390x running newer Ubuntu releases (especially needed in the context of secure execution) the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs to be enabled and set to 'y'. [Test Case] * Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive) * Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only available on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used. When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility. Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting) * Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe: 1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning) 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest) 3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff 4) Guest power off testing: Power off the device from within the guest, verify that the device is unusable in the guest, power the device back on within the guest and verify that the device is once again usable. 5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot) [Regression Potential] * The regression potential is moderate, since the code is upstream for quite a while and already enabled in jammy. * The general way on using passthrough has not changed, with this change (config option) it's now just possible to passthrough zPCI on top. * CCW devices are not affected. * And this is s390x-specific anyway, so no other architectures are affected. [Other] * The enabling of the kernel config option is exactly the same for L, M and U/N, but I submitted separate patches due to slightly different context and offsets. __ === Description by mjros...@us.ibm.com === LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to enable enhanced interpretation of PCI passthrough on s390. It also included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which is necessary to activate this kernel feature. For lunar and mantic, the kernel code did not require backporting due to the base kernel version already
[Kernel-packages] [Bug 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x
Hello, since the "noble"/24.04 development just started, may I ask if you/IBM have/has any updates or an opinion if it is be okay to switch off COMPAT_32BIT_TIME? (We would like to do switch this off for all architectures.) ** Tags added: noble -- 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/2038583 Title: Turning COMPAT_32BIT_TIME off on s390x Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: This will prevent existing s390 binaries to operate correctly, if they are still using 32bit time. 24.04 LTS is likely to be used for 10 years. And if allowed to overrun and remain active in the field in 2038 can lead to catastrophic failure in the field due to these syscalls enabled and used. I would like to request if we can turn off COMPAT_32BIT_TIME on every architecture, thus this will be arch by arch bug report, and arch by arch decision. This needs to be a per-arch decision, potentially taking into consideration bi-arch userspace support. config COMPAT_32BIT_TIME bool "Provide system calls for 32-bit time_t" default !64BIT || COMPAT help This enables 32 bit time_t support in addition to 64 bit time_t support. This is relevant on all 32-bit architectures, and 64-bit architectures as part of compat syscall handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2038583/+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
