[Kernel-packages] [Bug 2064530] [NEW] Include support for .NET 8 for Ubuntu on Power

2024-05-01 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-ppc64le bugnameltc-206154 severity-medium 
targetmilestone-inin2404

** Tags added: architecture-ppc64le bugnameltc-206154 severity-medium
targetmilestone-inin2404

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2064530

Title:
  Include support for .NET 8 for Ubuntu on Power

Status in linux 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/+source/linux/+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 2064345] [NEW] Power guest secure boot with key management: userspace portion

2024-04-30 Thread bugproxy
Public bug reported:

Covering the userspace portion (secvarctl)

Feature:

This feature comprises PowerVM LPAR guest OS kernel verification to
extend the chain of trust from partition firmware to the OS kernel and
includes key management.  GRUB and the host OS kernel are signed with 2
separate public key pairs.  Partition firmware includes the the public
verification key for GRUB in its build and uses it to verify GRUB.  GRUB
includes the public verification key for the OS kernel in its build and
uses it to verify the OS kernel image

Test case:

If secure boot is switched off, any GRUB and kernel boots.
If secure boot is switched on:
  - Properly signed GRUB boots.
  - Improperly signed GRUB does not boot.
  - Tampered signed GRUB does not boot.
  - Properly signed kernels boot.
  - Improperly signed kernels do not boot.
  - Tampered signed kernels do not boot.
TPM PCRs are extended roughly following the TCG PC Client and UEFI specs as 
they apply to POWER.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-ppc64le bugnameltc-205843 severity-critical 
targetmilestone-inin2404

** Tags added: architecture-ppc64le bugnameltc-205843 severity-critical
targetmilestone-inin2404

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2064345

Title:
  Power guest secure boot with key management: userspace portion

Status in linux package in Ubuntu:
  New

Bug description:
  Covering the userspace portion (secvarctl)

  Feature:

  This feature comprises PowerVM LPAR guest OS kernel verification to
  extend the chain of trust from partition firmware to the OS kernel and
  includes key management.  GRUB and the host OS kernel are signed with
  2 separate public key pairs.  Partition firmware includes the the
  public verification key for GRUB in its build and uses it to verify
  GRUB.  GRUB includes the public verification key for the OS kernel in
  its build and uses it to verify the OS kernel image

  Test case:

  If secure boot is switched off, any GRUB and kernel boots.
  If secure boot is switched on:
- Properly signed GRUB boots.
- Improperly signed GRUB does not boot.
- Tampered signed GRUB does not boot.
- Properly signed kernels boot.
- Improperly signed kernels do not boot.
- Tampered signed kernels do not boot.
  TPM PCRs are extended roughly following the TCG PC Client and UEFI specs as 
they apply to POWER.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064345/+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 2064321] [NEW] Power guest secure boot with key management: kernel portion

2024-04-30 Thread bugproxy
Public bug reported:

Covering the kernel portion

Feature:

This feature comprises PowerVM LPAR guest OS kernel verification using
static keys to extend the chain of trust from partition firmware to the
OS kernel.  GRUB and the host OS kernel are signed with 2 separate
public key pairs.  Partition firmware includes the the public
verification key for GRUB in its build and uses it to verify GRUB.  GRUB
includes the public verification key for the OS kernel in its build and
uses it to verify the OS kernel image

Test case:

If secure boot is switched off, any GRUB and kernel boots.
If secure boot is switched on:
  - Properly signed GRUB boots.
  - Improperly signed GRUB does not boot.
  - Tampered signed GRUB does not boot.
  - Properly signed kernels boot.
  - Improperly signed kernels do not boot.
  - Tampered signed kernels do not boot.
TPM PCRs are extended roughly following the TCG PC Client and UEFI specs as 
they apply to POWER.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-ppc64le bugnameltc-205842 severity-critical 
targetmilestone-inin2404

** Tags added: architecture-ppc64le bugnameltc-205842 severity-critical
targetmilestone-inin2404

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2064321

Title:
  Power guest secure boot with key management: kernel portion

Status in linux package in Ubuntu:
  New

Bug description:
  Covering the kernel portion

  Feature:

  This feature comprises PowerVM LPAR guest OS kernel verification using
  static keys to extend the chain of trust from partition firmware to
  the OS kernel.  GRUB and the host OS kernel are signed with 2 separate
  public key pairs.  Partition firmware includes the the public
  verification key for GRUB in its build and uses it to verify GRUB.
  GRUB includes the public verification key for the OS kernel in its
  build and uses it to verify the OS kernel image

  Test case:

  If secure boot is switched off, any GRUB and kernel boots.
  If secure boot is switched on:
- Properly signed GRUB boots.
- Improperly signed GRUB does not boot.
- Tampered signed GRUB does not boot.
- Properly signed kernels boot.
- Improperly signed kernels do not boot.
- Tampered signed kernels do not boot.
  TPM PCRs are extended roughly following the TCG PC Client and UEFI specs as 
they apply to POWER.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064321/+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 2060039] Comment bridged from LTC Bugzilla

2024-04-24 Thread bugproxy
--- Comment From hbath...@in.ibm.com 2024-04-24 12:23 EDT---
Posted the patches to reduce memory consumption for KFENCE upstream:

https://lore.kernel.org/all/20240424110926.184077-1-hbath...@linux.ibm.com/
("[PATCH 1/2] radix/kfence: map __kfence_pool at page granularity")

https://lore.kernel.org/all/20240424110926.184077-1-hbath...@linux.ibm.com/
("[PATCH 2/2] radix/kfence: support late __kfence_pool allocation")

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

Title:
  [Ubuntu-24.04] FADump with recommended crash size is making the L1
  hang

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Problem description :
  ==

  Triggered FADump with the recommended crash. L1 host got hung.

  As per the public document
  https://wiki.ubuntu.com/ppc64el/Recommendations recommended crash
  kernel size is 1024M for the system. But with 1024M and 2048M, the L1
  is getting hanged. with 4096, crash is generated and collected.

  
  root@ubuntu2404:~# uname -ar
  Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 
ppc64le ppc64le ppc64le GNU/Linux

  
  root@ubuntu2404:~# free -h
 totalusedfree  shared  buff/cache   
available
  Mem:48Gi   1.7Gi46Gi13Mi   687Mi
46Gi
  Swap:  8.0Gi  0B   8.0Gi

  
  root@ubuntu2404:~# cat /proc/cmdline 
  BOOT_IMAGE=/vmlinux-6.8.0-11-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv 
ro fadump=on crashkernel=1024M

  
  root@ubuntu2404:~# dmesg | grep -i reser
  [0.00] fadump: Reserved 1024MB of memory at 0x004000 (System 
RAM: 51200MB)
  [0.00] fadump: Initialized 0x4000 bytes cma area at 1024MB from 
0x4007 bytes of memory reserved for firmware-assisted dump
  [0.00] Memory: 49316672K/52428800K available (23616K kernel code, 
4096K rwdata, 25536K rodata, 8832K init, 2487K bss, 2063552K reserved, 1048576K 
cma-reserved)
  [0.396408] ibmvscsi 3066: Client reserve enabled

  
  root@ubuntu2404:~# kdump-config show
  DUMP_MODE:fadump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
 /var/lib/kdump/vmlinuz
  kdump initrd: 
 /var/lib/kdump/initrd.img
  current state:ready to fadump

  IBM is looking to update the crash kernel reservations section of the
  wiki for Power.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060039/+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] Comment bridged from LTC Bugzilla

2024-04-24 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-04-24 02:47 EDT---
Hi,
We have had a reply from the AIX support team (see below) explaining the RENEW 
requests. Do you have any further questions for the AIX support team or can we 
supply any further diagnostic information to progress this issue ?

Regarding the comment/question about RENEW reqs from Linux:

RENEW is done when half the lease period has elapsed without any state
operation going on.

Here, the Linux server's lease is 90 seconds. From an NFS perspective,
there is nothing strange or remarkable about the pattern of RENEW reqs
sent in the good & bad cases. If there is a specific question about
renews in the latest captures let us know.

-- 
You 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 2062556] [NEW] [Ubuntu-24.04] Hugepage memory is not getting released even after destroying the guest!

2024-04-19 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-ppc64le bugnameltc-206058 severity-high 
targetmilestone-inin2404

** Tags added: architecture-ppc64le bugnameltc-206058 severity-high
targetmilestone-inin2404

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2062556

Title:
  [Ubuntu-24.04] Hugepage memory is not getting released even after
  destroying the guest!

Status in linux package in Ubuntu:
  New

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/+source/linux/+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 2042363] Comment bridged from LTC Bugzilla

2024-04-18 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-04-18 11:00 EDT---
Hi,
Thanks for looking at the logs. I agree that both syslogs (AIX 7.2 and 7.3) 
contain multiple "TCP recvfrom got EAGAIN" entries.

To clarify the information in the attachments, I have updated the
comment for the attachments of the syslog for the non-working AIX 7.3
pair (amaliada and adamsongrunter. The syslog is in two parts because
the Bugzilla file uploader couldn't handle such a large file. It is NOT
mixed with the AIX 7.2 syslog.

The syslog for the working pair AIX 7.2 (adia and amberjack) was
smaller, so it is a single file attachment.

I will ask the IBM AIX support team about the NFS Client lease renewal
in both AIX 7.2 and 7.3.

-- 
You 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 2042363] Comment bridged from LTC Bugzilla

2024-04-17 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-04-17 13:11 EDT---
Here are the details of the IP addresses for the tcpdump files

AIX 7.3
9.20.120.112name = amaliada.v6.hursley.ibm.com   -- Primary
9.20.120.153   name = adamsongrunter.v6.hursley.ibm.com  ? Partner

AIX 7.2
9.20.120.127name = adia.v6.hursley.ibm.com   -- Primary
9.20.121.46 name = amberjack.v6.hursley.ibm.com  ? Partner

NFSv4 server
9.20.32.85 name =   duckseason.hursley.ibm.com

-- 
You 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 2042363] tcpdump for aix 7.2 testing part 3 of 4

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:18 
EDT---


** Attachment added: "tcpdump for aix 7.2 testing part 3 of 4"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766766/+files/tcpdump17_04_2024_09H_10M2.zip

-- 
You 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 2042363] tcpdump for aix 7.2 testing part 4 of 4

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:19 
EDT---


** Attachment added: "tcpdump for aix 7.2 testing part 4 of 4"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766767/+files/tcpdump17_04_2024_09H_10M3.zip

-- 
You 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 2042363] tcpdump for aix 7.2 testing part 2 of 4

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:18 
EDT---


** Attachment added: "tcpdump for aix 7.2 testing part 2 of 4"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766765/+files/tcpdump17_04_2024_09H_10M1.zip

-- 
You 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 2042363] tcpdump for aix 7.3 testing part 5 of 5

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:16 
EDT---


** Attachment added: "tcpdump for aix 7.3 testing part 5 of 5"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766763/+files/tcpdump16_04_2024_14H_03M4.zip

-- 
You 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 2042363] tcpdump for aix 7.3 testing part 4 of 5

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:16 
EDT---


** Attachment added: "tcpdump for aix 7.3 testing part 4 of 5"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766762/+files/tcpdump16_04_2024_14H_03M3.zip

-- 
You 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 2042363] tcpdump for aix 7.2 testing part 1 of 4

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:17 
EDT---


** Attachment added: "tcpdump for aix 7.2 testing part 1 of 4"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766764/+files/tcpdump17_04_2024_09H_10M.zip

-- 
You 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 2042363] tcpdump for aix 7.3 testing part 3 of 5

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:15 
EDT---


** Attachment added: "tcpdump for aix 7.3 testing part 3 of 5"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766761/+files/tcpdump16_04_2024_14H_03M2.zip

-- 
You 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 2042363] tcpdump for aix 7.3 testing part 1 of 5

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:14 
EDT---


** Attachment added: "tcpdump for aix 7.3 testing part 1 of 5"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766759/+files/tcpdump16_04_2024_14H_03M.zip

-- 
You 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 2042363] tcpdump for aix 7.3 testing part 2 of 5

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:15 
EDT---


** Attachment added: "tcpdump for aix 7.3 testing part 2 of 5"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766760/+files/tcpdump16_04_2024_14H_03M1.zip

-- 
You 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 2042363] Syslog for AIX 7.2 primary and partner

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:12 
EDT---


** Attachment added: "Syslog for AIX 7.2 primary and partner"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766758/+files/syslog_17042024_adia_primary_amberjack_partner_both_aix72.zip

-- 
You 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 2042363] Syslog and tcpdump file covering a working AIX 7.2 and non-working AIX 7.3 pair of machines using the same NFSv4 server

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:10 
EDT---


** Attachment added: "Syslog and tcpdump file covering a working AIX 7.2 and 
non-working AIX 7.3 pair of machines  using the same NFSv4 server"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766756/+files/syslog_16042024_amaliada_primary_adamsongrunter_partner_both_aix73_part1.zip

-- 
You 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 2042363] Syslog and tcpdump file covering a working AIX 7.2 and non-working AIX 7.3 pair of machines using the same NFSv4 server

2024-04-17 Thread bugproxy
--- Comment (attachment only) From david_pa...@uk.ibm.com 2024-04-17 06:11 
EDT---


** Attachment added: "Syslog and tcpdump file covering a working AIX 7.2 and 
non-working AIX 7.3 pair of machines  using the same NFSv4 server"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5766757/+files/syslog_16042024_amaliada_primary_adamsongrunter_partner_both_aix73_part2.zip

-- 
You 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 2042363] Comment bridged from LTC Bugzilla

2024-04-17 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-04-17 05:37 EDT---
Hi,
I have run the same MQ HA test on a working(AIX 7.2) and non working(AIX 7.3) 
pair of machines with the same Linux NVSv4 Ubuntu 20.04 (kernel updated to 
5.4.0-176-generic). I used the same RPC debug trace options as previously.

Here are the details of the uploaded tar.gz file called
CASE_TS012306761.tar.gz. I do have other trace files if you need them.

AIX 7.3 test was between machine amaliada and partner adamsongrunter on
16/04/2024 starting at 14:01 and failing at 14:04:07:971116 with a
failure to write a file on the shared NFSv4 server.

There is a partial syslog from the Linux NVSv4 server duckseason
covering that period called
TS012306761/syslog_16042024_amaliada_primary_adamsongrunter_partner_both_aix73.log

Covering the same period, there are a set of tcpdump files in subfolder
TS012306761/tcpdumps_amaliada_primary_admasongrunter_partner_both_aix73/


AIX 7.2 test was between primary machine adia and partner amberjack on 
17/04/2024 starting at 09:09:48 and ending successfully at 09:16:29.

There is a partial syslog from the linux NVSv4 server duckseason
covering that period called
TS012306761/syslog_17042024_adia_primary_amberjack_partner_both_aix72.log

Covering the same period, there are a set of tcpdump files in subfolder
TS012306761/tcpdumps_adia_primary_amberjack_partner_both_aix72/

We are happy to supply further info to help resolve this issue. Thanks
for your help and advice.

-- 
You 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 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`

2024-04-15 Thread bugproxy
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2004

-- 
You 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 2059237] Comment bridged from LTC Bugzilla

2024-04-13 Thread bugproxy
--- Comment From kowshik.j...@in.ibm.com 2024-04-13 13:57 EDT---
With the latest kernel, issue is not getting reproduced. Hence closing this bug.

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

[Kernel-packages] [Bug 2060217] Comment bridged from LTC Bugzilla

2024-04-11 Thread bugproxy
--- Comment From vasily.gor...@de.ibm.com 2024-04-11 05:50 EDT---
I've sent a fix proposal to mailing lists
https://lore.kernel.org/all/patch.git-0ff58649313e.your-ad-here.call-01712828617-ext-4049@work.hours/

-- 
You 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 2060217] Comment bridged from LTC Bugzilla

2024-04-10 Thread bugproxy
--- Comment From vasily.gor...@de.ibm.com 2024-04-10 11:16 EDT---
bisected it to commit fce7913b13d0 ("NFSD: Use a bitmask loop to encode FATTR4 
results")
Looks like an unfixed endianness issue since v6.7.

commit fce7913b13d0270bcf926f986b7ef329e2e56eec
Author: Chuck Lever 
Date:   Mon Sep 18 10:02:12 2023 -0400

NFSD: Use a bitmask loop to encode FATTR4 results
The fattr4 encoder is now structured like the COMPOUND op encoder:
one function for each individual attribute, called by bit number.
Benefits include:
- The individual attributes are now guaranteed to be encoded in
bitmask order into the send buffer

- There can be no unwanted side effects between attribute encoders

- The code now clearly documents which attributes are /not/
implemented on this server

Reviewed-by: Jeff Layton 
Signed-off-by: Chuck Lever 

-- 
You 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 2060807] [NEW] [UBUNTU 24.04] s390x: clone clobbers r7

2024-04-10 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s3903164 bugnameltc-205730 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s3903164 bugnameltc-205730 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2060807

Title:
  [UBUNTU 24.04] s390x: clone clobbers r7

Status in linux package in Ubuntu:
  New

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/+source/linux/+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

2024-04-09 Thread bugproxy
** Tags added: architecture-s39064 bugnameltc-206018 severity-high
targetmilestone-inin---

-- 
You 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 2060039] Comment bridged from LTC Bugzilla

2024-04-08 Thread bugproxy
--- Comment From hbath...@in.ibm.com 2024-04-08 07:09 EDT---
CONFIG_KFENCE is the config option that is increasing the memory requirement
significantly for radix MMU.

For radix MMU case, memory is direct mapped with 2MB size.
But when KFENCE is used, direct mapping is done at pagesize granularity (64K).
This sharply increased the page table allocation size, on a 100GB system,
from ~23MB to ~3223MB with CONFIG_KFENCE. Experimenting to find if this
memory requirement can be brought down. If not, thinking of disabling KFENCE
for dump capture environment.

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

Title:
  [Ubuntu-24.04] FADump with recommended crash size is making the L1
  hang

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Problem description :
  ==

  Triggered FADump with the recommended crash. L1 host got hung.

  As per the public document
  https://wiki.ubuntu.com/ppc64el/Recommendations recommended crash
  kernel size is 1024M for the system. But with 1024M and 2048M, the L1
  is getting hanged. with 4096, crash is generated and collected.

  
  root@ubuntu2404:~# uname -ar
  Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 
ppc64le ppc64le ppc64le GNU/Linux

  
  root@ubuntu2404:~# free -h
 totalusedfree  shared  buff/cache   
available
  Mem:48Gi   1.7Gi46Gi13Mi   687Mi
46Gi
  Swap:  8.0Gi  0B   8.0Gi

  
  root@ubuntu2404:~# cat /proc/cmdline 
  BOOT_IMAGE=/vmlinux-6.8.0-11-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv 
ro fadump=on crashkernel=1024M

  
  root@ubuntu2404:~# dmesg | grep -i reser
  [0.00] fadump: Reserved 1024MB of memory at 0x004000 (System 
RAM: 51200MB)
  [0.00] fadump: Initialized 0x4000 bytes cma area at 1024MB from 
0x4007 bytes of memory reserved for firmware-assisted dump
  [0.00] Memory: 49316672K/52428800K available (23616K kernel code, 
4096K rwdata, 25536K rodata, 8832K init, 2487K bss, 2063552K reserved, 1048576K 
cma-reserved)
  [0.396408] ibmvscsi 3066: Client reserve enabled

  
  root@ubuntu2404:~# kdump-config show
  DUMP_MODE:fadump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
 /var/lib/kdump/vmlinuz
  kdump initrd: 
 /var/lib/kdump/initrd.img
  current state:ready to fadump

  IBM is looking to update the crash kernel reservations section of the
  wiki for Power.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060039/+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] Comment bridged from LTC Bugzilla

2024-04-07 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-04-07 20:28 EDT---
This is great news but was there something in particular y'all are aware of 
that fixed the issue?

-- 
You 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 2056491] Comment bridged from LTC Bugzilla

2024-04-02 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-04-02 11:43 EDT---
Can you check if vTPM is enabled and disable it and see if that allows you to 
install?

-- 
You 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:
  Confirmed

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 2060039] grub file

2024-04-02 Thread bugproxy
Default Comment by Bridge

** Attachment added: "grub file"
   
https://bugs.launchpad.net/bugs/2060039/+attachment/5761301/+files/etc_default_grub.txt

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2060039

Title:
  [Ubuntu-24.04] FADump with recommended crash size is making the L1
  hang

Status in linux package in Ubuntu:
  New

Bug description:
  Problem description :
  ==

  Triggered FADump with the recommended crash. L1 host got hung.

  As per the public document
  https://wiki.ubuntu.com/ppc64el/Recommendations recommended crash
  kernel size is 1024M for the system. But with 1024M and 2048M, the L1
  is getting hanged. with 4096, crash is generated and collected.

  
  root@ubuntu2404:~# uname -ar
  Linux ubuntu2404 6.8.0-11-generic #11-Ubuntu SMP Wed Feb 14 00:33:03 UTC 2024 
ppc64le ppc64le ppc64le GNU/Linux

  
  root@ubuntu2404:~# free -h
 totalusedfree  shared  buff/cache   
available
  Mem:48Gi   1.7Gi46Gi13Mi   687Mi
46Gi
  Swap:  8.0Gi  0B   8.0Gi

  
  root@ubuntu2404:~# cat /proc/cmdline 
  BOOT_IMAGE=/vmlinux-6.8.0-11-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv 
ro fadump=on crashkernel=1024M

  
  root@ubuntu2404:~# dmesg | grep -i reser
  [0.00] fadump: Reserved 1024MB of memory at 0x004000 (System 
RAM: 51200MB)
  [0.00] fadump: Initialized 0x4000 bytes cma area at 1024MB from 
0x4007 bytes of memory reserved for firmware-assisted dump
  [0.00] Memory: 49316672K/52428800K available (23616K kernel code, 
4096K rwdata, 25536K rodata, 8832K init, 2487K bss, 2063552K reserved, 1048576K 
cma-reserved)
  [0.396408] ibmvscsi 3066: Client reserve enabled

  
  root@ubuntu2404:~# kdump-config show
  DUMP_MODE:fadump
  USE_KDUMP:1
  KDUMP_COREDIR:/var/crash
 /var/lib/kdump/vmlinuz
  kdump initrd: 
 /var/lib/kdump/initrd.img
  current state:ready to fadump

  IBM is looking to update the crash kernel reservations section of the
  wiki for Power.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060039/+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] Comment bridged from LTC Bugzilla

2024-04-01 Thread bugproxy
--- Comment From hariharan...@ibm.com 2024-04-01 04:37 EDT---
Kowshik, Can we close the defect.

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

[Kernel-packages] [Bug 2056373] Comment bridged from LTC Bugzilla

2024-03-29 Thread bugproxy
--- Comment From jldo...@us.ibm.com 2024-03-29 11:18 EDT---
I tested to see if mkvterm was performing as expected with the kernel in 
focal-proposed, and the behavior was correct. Ritu in Novalink did as well.

In addition to that, the kernel was installed on two different lpars,
and another engineer within IBM performed basic tests and stress tests.
All tests passed. HVCS is working as expected. Many thanks

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

[Kernel-packages] [Bug 2059237] Comment bridged from LTC Bugzilla

2024-03-28 Thread bugproxy
--- Comment From kowshik.j...@in.ibm.com 2024-03-28 11:43 EDT---
(In reply to comment #13)
Hello Frank,

I upgraded the system to 6.8.0-20-generic kernel and the issue is not
seen even after multiple reboots.

Also. I took the source available here:
http://launchpadlibrarian.net/720006283/linux-
source-6.8.0_6.8.0-20.20_all.deb

I see that, the above mentioned patch is not applied in this source. So,
if the issue is getting fixed without the patch, is there a need for
this patch?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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 

[Kernel-packages] [Bug 2050019] Comment bridged from LTC Bugzilla

2024-03-28 Thread bugproxy
--- Comment From fre...@de.ibm.com 2024-03-28 03:42 EDT---
(In reply to comment #13)
> Well, I was not able to easily cherry-pick these t commits.
> I got merge conflicts due to several debug lines.
>
> After some investigations (using git blame) I found that the commits:
> 0ccac4529540 s390/pkey: harmonize pkey s390 debug feature calls
> 6d749b4e0208 s390/pkey: introduce dynamic debugging for pkey
> seem to be needed - then even some more.
> I finally found that adding the following set of commits (that I've found as
> block earlier in git log):
> 88e4c0da9b08 s390/zcrypt: harmonize debug feature calls and defines
> 08b2c3706de2 s390/zcrypt: introduce dynamic debugging for AP and zcrypt code
> 0ccac4529540 s390/pkey: harmonize pkey s390 debug feature calls
> 6d749b4e0208 s390/pkey: introduce dynamic debugging for pkey
> 6a2892d09df5 s390/ap: add debug possibility for AP messages
> b69b65f51148 s390/zcrypt: add debug possibility for CCA and EP11 messages
> helped me to apply the initial commits.
>
> And with that I was also able to build a test kernel in PPA:
> https://launchpad.net/~fheimes/+archive/ubuntu/lp2050019
>
> Please can you confirm that it's reasonable to go with these (in total now)
> 13 commits instead?

Well, dependent on your kernel base you may need to pull in some more fixes. 
Best is to simple follow the commit chain. For example with an
git log drivers/s390/crypto
you get the commit chain. Filter out the vfio stuff (or even simpler, pick it 
also) - this way you get an update of the while AP bus + zcrypt + pkey + vfio 
stuff. Dependencies to the rest of the kernel are rare and can usually be 
solved simple by pulling in one patch or so.
Doing the update this way keeps the code consistent and ready for future 
backports.

-- 
You 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 2059303] Comment bridged from LTC Bugzilla

2024-03-27 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2024-03-27 16:09 EDT---
Full list of patches:

a54daf459e7504c0f42d3eb028100b7ab07894ff ("pvattest: Fix root-ca parsing")
5e1cb58a21ae0707d1993de3c8fc078c5cffed88 ("libpv: Support `Armonk` in IBM 
signing key subject")
d14e7593cc6380911ca42b09e11c53477ae13d5c ("genprotimg: support `Armonk` in IBM 
signing key subject")
1a3d0b74f7819f5e087e6ecbf3ec879a05a88bbc ("rust/pv: Support `Armonk` in IBM 
signing key subject")

-- 
You 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 linux 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/+source/linux/+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] Comment bridged from LTC Bugzilla

2024-03-27 Thread bugproxy
--- Comment From kowshik.j...@in.ibm.com 2024-03-27 15:59 EDT---
>
> 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?

Hello Frank,

This issue happened on a P10 Denali LPAR(KVM on PowerVM)

I haven't built any custom kernel. Per my chat discussion records with
my team, https://cdimage.ubuntu.com/ubuntu-server/daily-
live/pending/noble-live-server-ppc64el.iso was the ISO I had used and I
had downloaded it around Feb 7-9 time frame.

Even with the latest ISO available as on today also this issue is
getting recreated.

Sure, I don't mind giving a try with ISO from proposed. Could you please
point me to the ISO path. I did a search but couldn't find it.

-- 
You 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] 

[Kernel-packages] [Bug 2059303] [NEW] [UBUNTU 20.04] SE-tooling: New IBM host-key subject locality (s390-tools)

2024-03-27 Thread bugproxy
Public bug reported:

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.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-205928 severity-critical 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-205928 severity-critical
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2059303

Title:
  [UBUNTU 20.04] SE-tooling: New IBM host-key subject locality
  (s390-tools)

Status in linux 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/+source/linux/+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] [NEW] [Ubuntu-24.04] "array-index-out-of-bounds" error is observed after every reboot

2024-03-27 Thread bugproxy
Public bug reported:

== 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
https://bugs.launchpad.net/ubuntu/+source/virtinst/+bug/2055126 was
created for tracking a different issue which is resolved. I just posted
a question about this issue as well at the end. But its been 20 days and
we haven't heard anything back on that. Also, the bug is already closed.
So I think it makes sense to initiate a new discussion with ubuntu on
this issue.

Earlier I had initiated a discussion through
https://bugs.launchpad.net/ubuntu/+bug/2052767 but no updates on that
one as well till now.


As you mentioned, compiled upstream kernel by disabling the UBSAN in the 

[Kernel-packages] [Bug 2056491] Comment bridged from LTC Bugzilla

2024-03-26 Thread bugproxy
--- Comment From kowshik.j...@in.ibm.com 2024-03-26 13:55 EDT---
I tried just now with the latest ISO image available on the site on a P10 
Denali LPAR and still facing the same issue.

---
error: out of memory.

Press any key to continue...

ISO used: https://cdimage.ubuntu.com/ubuntu-server/daily-
live/20240326/noble-live-server-ppc64el.iso

I am not able to print "real-base" values as well. I tried setting the
value but faced the same issue even after that.

Memory  Keyboard Network Speaker  ok
0 > printenv real-base
ok
0 > setenv real-base c0  ok
0 > printenv real-base
ok
0 >

-- 
You 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 2056491] Comment bridged from LTC Bugzilla

2024-03-26 Thread bugproxy
--- Comment From iranna.an...@in.ibm.com 2024-03-26 10:05 EDT---
(In reply to comment #7)
> Hi Chavez, thanks for checking it. I see this output:
> ```
> Memory  Keyboard Network Speaker  ok
> 0 > printenv real-base
> -- Partition: common  Signature: 0x70 ---
> real-basec0  c0
> ok
> 0 >
> ```
> I'm able to install Ubuntu Jammy 22.04 LTS into the same partitions. ISO via
> Virtual target device.
>
> I don't see the same error when trying an older image - working installation.
>
> Let me know if you need any other info.

Hi Patricia,
Just wondering did you try installing Ubuntu 24.04 after resetting those 
real-base values? We hope 24.04 installation should also go fine.

Thanks!

-- 
You 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] [NEW] [UBUNTU 24.04] dbginfo.sh: updates required for /bin/dash shell

2024-03-25 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s3903164 bugnameltc-205909 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s3903164 bugnameltc-205909 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2058944

Title:
  [UBUNTU 24.04] dbginfo.sh: updates required for /bin/dash shell

Status in linux 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/+source/linux/+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 2056491] Comment bridged from LTC Bugzilla

2024-03-19 Thread bugproxy
--- Comment From jldo...@us.ibm.com 2024-03-19 20:42 EDT---
*** Bug 205873 has been marked as a duplicate of this bug. ***

-- 
You 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 2056491] Comment bridged from LTC Bugzilla

2024-03-19 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-03-19 14:42 EDT---
Regarding the main issue with the unable to mount to root, do you get the same 
errors prior to it as in the working installation? Are the kernel commandline 
the same? Any other differences?

-- 
You 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 2056491] Comment bridged from LTC Bugzilla

2024-03-19 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-03-19 14:32 EDT---
error: out of memory.

Press any key to continue...

The above messages are likely coming from the bootloader (grub2). Which
version of grub2 is being used? How exactly is the install being done,
e.g. via USB or some other method?

Can you try booting into the openfirmware prompt (Press 8 after
restarting or activating the LPAR) and print out the real-base value? It
should hopefully be set to the default value of 0xC0.

0 > printenv real-base
-- Partition: common  Signature: 0x70 ---
real-basec0  c0
ok

If not 0xC0 then try setting it with

0 > setenv real-base c0

-- 
You 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 2042363] Comment bridged from LTC Bugzilla

2024-03-19 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-03-19 13:53 EDT---
Is there an update from Canonical please? Can we provide any further 
information or trace to help diagnose this issue ?

-- 
You 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 2056491] Re: not able to install noble on PowerVM LPARs `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block`

2024-03-19 Thread bugproxy
** Tags added: architecture-ppc64le bugnameltc-205876 severity-medium
targetmilestone-inin---

-- 
You 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 1903288] Comment bridged from LTC Bugzilla

2024-03-12 Thread bugproxy
--- Comment From gcwil...@us.ibm.com 2024-03-12 17:34 EDT---
Closing on our side as ALT_SOLUTION_AVAIL.

-- 
You 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 2056373] Comment bridged from LTC Bugzilla

2024-03-11 Thread bugproxy
--- Comment From jldo...@us.ibm.com 2024-03-11 14:00 EDT---
Thank you Frank for providing a test kernel! I have installed the test kernel 
and everything appears to be working smoothly.

---
root@neop91:/home/neo# mkvterm --id 2
vterm for partition 2 is active.  Press Control+] to exit.
IBM Virtual I/O Server

login:
Cleaning up...
vterm closed
---

syslog:

---
Mar 11 17:52:13 neop91 kernel: [   50.767514] HVCS: Driver registered.
Mar 11 17:52:13 neop91 drmgr: drmgr: -c slot -s U9080.M9S.13073A8-V1-C6 -a -w 3
Mar 11 17:52:13 neop91 kernel: [   50.853870] rpaphp: RPA HOT Plug PCI 
Controller Driver version: 0.1
Mar 11 17:52:13 neop91 kernel: [   51.030821] HVCS: vty-server@3006 added 
to the vio bus.
Mar 11 17:52:13 neop91 kernel: [   51.030860] rpadlpar_io: slot 
U9080.M9S.13073A8-V1-C6 added
Mar 11 17:52:16 neop91 kernel: [   53.899124] HVCS: vty-server@3006 
connection opened.
Mar 11 17:52:23 neop91 kernel: [   61.344106] HVCS: Closed vty-server@3006 
and partner vty@3000:2 connection.
Mar 11 17:52:24 neop91 drmgr: drmgr: -c slot -s U9080.M9S.13073A8-V1-C6 -r -w 3
Mar 11 17:52:24 neop91 kernel: [   61.468923] HVCS: Destroyed hvcs_struct for 
vty-server@3006.
Mar 11 17:52:24 neop91 kernel: [   61.468925] HVCS: vty-server@3006 removed 
from the vio bus.
Mar 11 17:52:24 neop91 kernel: [   61.468971] rpadlpar_io: slot 
U9080.M9S.13073A8-V1-C6 removed
---

HVCS is being probed and rpadlpar_io is adding the slot information
correctly. When mkvterm closes the connection with Ctrl+], HVCS is
closing the connection properly and behaving as expected.

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

[Kernel-packages] [Bug 2042363] Comment bridged from LTC Bugzilla

2024-03-11 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2024-03-11 03:51 EDT---
Has there been any further progress on this issue from the Linux NFS 
development team ?

The AIX NFS development team will not progress the problem from their
side until they understand why the BAD_SEQID errors has been returned
from the Linux NFSv4 server.

-- 
You 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 2056574] ss2

2024-03-08 Thread bugproxy
Default Comment by Bridge

** Attachment added: "ss2"
   
https://bugs.launchpad.net/bugs/2056574/+attachment/5754069/+files/Captura_de_pantalla_2024-03-06_202037.png

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2056574

Title:
  Can't install Ubuntu 23.10 bot from SAN

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment:- Melisa Arzola Ruiz ==
  ---Problem Description---
  I want to install the Ubuntu 23.10 version and the installer has restarted 
for an error 
   
  Contact Information = melisa.arz...@ibm.com 
   
  ---Steps to Reproduce---
   Insert an USB With an Ubuntu 23.10 image
  try to install the operative system 
  select the LUN (should be bot from SAN)
  the installer crash 
   
  ---uname output---
  N/A
   
  ---Debugger---
  A debugger is not configured
   
  ---Additional Hardware Info---
  hosts 
  HBA
  Brand:Lenovo  Model:  X3650 M5: 5462-AC1
  Memory:   64 GB
  HBA
  Brand:Lenovo  Model:  LPe32002-M2-L
  Brand:EMULEX  Model:  10GbE VFA3 PCIe: IBM 95Y3766

  DS8000

  Release
  9.4 bundle 89.40.48.0
  Product
  DS8910F

  Connected via Fiber channel  on switches 
   Brand:   Broadcomm   Model:  G620
  Brand:BROCADE Model:  G630  

   
  Machine Type = Lenovo X3650 M5: 5462-AC1 
   
  Userspace tool common name: N/A 

  Userspace rpm: N/A 
   
  The userspace tool has the following bit modes: N/A 

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for melisa.arz...@ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.
  -Attach:
/proc/partitions
/proc/mounts/
/etc/lvm/lvm.conf
dmsetup ls
dmsetup table
dmsetup targets
dmsetup version
lvm version

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056574/+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] [NEW] [UBUNTU 20.04] Cannot use vfio-ccw dasd passthrough for KVM guests under Ubuntu

2024-03-07 Thread bugproxy
Public bug reported:

---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,
  "/dev/vhost-net" rw,
  "/dev/vfio/2" rwk,

(The passed through DASD device is /dev/vfio/2 in the above list, not
/dev/dasdb. The latter is the guest rootfs, connected via virtio-blk.)

=== Comment:  - 2024-03-06 13:30:45 
=
Verified that this still misbehaves with 20.04.6 and 22.04.4. Both with the 
manual sysfs changes described in the initial comment, and the more convenient 
driverctl and mdevctl tooling.

=== Comment:  - 2024-03-06 13:34:28 
=
eric@host:~# virsh attach-device guest_3c4c 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@host:~# dmesg | grep 0165
[  127.558194] vfio_ccw 

[Kernel-packages] [Bug 2056373] [NEW] Multiple issues found on Ubuntu 20.04 against HVCS

2024-03-06 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-ppc64le bugnameltc-205798 severity-high 
targetmilestone-inin2004

** Tags added: architecture-ppc64le bugnameltc-205798 severity-high
targetmilestone-inin2004

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/2056373

Title:
  Multiple issues found on Ubuntu 20.04 against HVCS

Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  

[Kernel-packages] [Bug 2055175] [NEW] [UBUNTU 23.10] s390x: clone clobbers r7

2024-02-27 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s3903164 bugnameltc-205731 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s3903164 bugnameltc-205731 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2055175

Title:
  [UBUNTU 23.10] s390x: clone clobbers r7

Status in linux 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/+source/linux/+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 2032247] Comment bridged from LTC Bugzilla

2024-02-26 Thread bugproxy
--- Comment From s...@de.ibm.com 2024-02-26 03:48 EDT---
Ubuntu noble 24.04 is using glibc 2.39 which includes the required patch:
> In glibc-upstream, this configure check is now adjusted and it allows 
> checking binutils by version number:
> commit "s390x: Fix static PIE condition for toolchain bootstrapping." (will 
> be in glibc 2.39)
> https://sourceware.org/git/?p=glibc.git;a=commit;h=f5f96b784beb3480e0e8d10e250ca7e6063ab881

The libc6-dev-s390x-cross package now contains the rcrt1.o file:
https://packages.ubuntu.com/noble/all/libc6-dev-s390x-cross/filelist
/usr/s390x-linux-gnu/lib/rcrt1.o

I've also upgraded to current pre-release of Ubuntu 24.04 and checked
that compiling/running a static pie program now works. Linking with
"-Wl,-v" also shows that rcrt1.o is now also used from
libc6-dev-s390x-cross package.

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

Title:
  [UBUNTU 23.04] S390: static-PIE programs segfaults if
  libc6-dev-s390x-cross package is installed

Status in Ubuntu on IBM z Systems:
  New
Status in gcc-12-cross package in Ubuntu:
  New
Status in gcc-13-cross package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == by Stefan  ==
  A simple helloworld program build and linked as static-PIE segfaults while 
startup in __libc_setup_tls:
  $ gcc -c -fPIE -static-pie -o hello.o hello.c
  $ gcc -o hello hello.o -static-pie

  Note:
  If only libc6-dev package is installed, all is fine.
  If both libc6-dev and libc6-dev-s390x-cross packages are installed, you will 
see the mentioned segfault.

  Linking with "-Wl,-v" dumps the used linker command and it shows the used 
startup-files:
  /usr/lib/s390x-linux-gnu/rcrt1.o => from libc6-dev
  /usr/s390x-linux-gnu/lib/crti.o => from libc6-dev-s390x-cross
  /usr/lib/gcc/s390x-linux-gnu/12/crtbeginS.o
  /usr/lib/gcc/s390x-linux-gnu/12/crtendS.o
  /usr/s390x-linux-gnu/lib/crtn.o => from libc6-dev-s390x-cross

  Linking as static-PIE requires the rcrt1.o file, which is not
  available in libc6-dev-s390x-cross package, but in libc6-dev. Due to
  this mixing of the startup-files, you get the segfault.

  This issue can be fixed by enabling static-PIE also in the 
libc6-dev-s390x-cross package, then all startup-files belong to the same 
package. For s390x static-PIE was introduced in glibc 2.36:
  commit "S390: Enable static PIE" (in glibc 2.36)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=728894dba4a19578bd803906de184a8dd51ed13c

  There is a configure check which do a link-test to ensure that a
  suitable binutils(ld) version is used. Afterwards static-PIE is
  automatically enabled. The required binutils-patches are first
  included in binutils 2.39.

  According to the build log of package cross-toolchain-base (see 
https://launchpad.net/ubuntu/+source/cross-toolchain-base/66ubuntu3/+build/25689036),
 the libc6-dev-s390x-cross package is cross-build on x86_64 and the mentioned 
configure check fails:
  running configure fragment for sysdeps/s390/s390-64
  checking for s390-specific static PIE requirements... no

  In this cross build, glibc is configured in order to first build the
  crt-startup-files, which are needed to complete the cross-gcc build.
  At this time, the sysroot does not contain the crt-files or libc.so
  itself. Thus the "linking" configure check is failing. After building
  the cross-gcc, glibc is build without re-configuring. Thus static-PIE
  is not enabled.

  In glibc-upstream, this configure check is now adjusted and it allows 
checking binutils by version number:
  commit "s390x: Fix static PIE condition for toolchain bootstrapping." (will 
be in glibc 2.39)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5f96b784beb3480e0e8d10e250ca7e6063ab881

  Perhaps you also have to pick the following commits by Sam James which 
adjusted the tests in between (both are in glibc 2.36):
  - commit "s390: use $READELF"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=c376ff3287b9b0f78a4f8951313c6dae60cbdfea
  - commit "s390: use LC_ALL=C for readelf call"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2249ec60a987f9a7aa585890de2bd365b3656d28


  In addition to the static-PIE configure-checks, there are those other 
s390-specific configure-checks to determine which IFUNC-optimizations can be 
build and used as default. Those also fail for libc6-dev-s390x-cross as linking 
is also involved:
  running configure fragment for sysdeps/s390
  checking for __builtin_tbegin... yes
  checking for S390 vector instruction support... no
  configure: WARNING: Use binutils with vector-support in order to use 
optimized implementations.
  checking for S390 vector support in gcc... no
  checking for S390 arch13 zarch instruction support... no
  checking for S390 z10 zarch instruction support as default... no
  checking for S390 z196 

[Kernel-packages] [Bug 2042363] Comment bridged from LTC Bugzilla

2024-02-13 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-02-13 16:49 EDT---
(In reply to comment #14)
> 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...

Thanks Frank! I hope you found someone else to help you. Please let us
know if y'all find anything of interest or you need additional
information from us.

-- 
You 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 2038587] Re: Turning COMPAT_32BIT_TIME off on ppc64el

2024-02-13 Thread bugproxy
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2004

-- 
You 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 2003374] Re: Undefined Behavior Sanitizer (UBSAN) causes failure to match symbols

2024-02-09 Thread bugproxy
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2204

-- 
You 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 UBAAN 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 2013088] uaccess clear_user() fix

2024-02-08 Thread bugproxy
--- Comment on attachment From h.carst...@de.ibm.com 2023-04-03 14:32 
EDT---


Attached patch applies to 18.04 and 20.04.

** Attachment added: "uaccess clear_user() fix"
   
https://bugs.launchpad.net/bugs/2013088/+attachment/5745283/+files/s390-uaccess.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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 2052696] [NEW] [UBUNTU 24.04] Haskell LLVM Backend: Objects of data section are missing alignment

2024-02-08 Thread bugproxy
Public bug reported:

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.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-205159 severity-high 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-205159 severity-high
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2052696

Title:
  [UBUNTU 24.04] Haskell LLVM Backend: Objects of data section are
  missing alignment

Status in linux package in Ubuntu:
  New

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/+source/linux/+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 2032247] Comment bridged from LTC Bugzilla

2024-02-02 Thread bugproxy
--- Comment From s...@de.ibm.com 2024-02-02 04:24 EDT---
are there any news regarding missing rcrt1.o?

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

Title:
  [UBUNTU 23.04] S390: static-PIE programs segfaults if
  libc6-dev-s390x-cross package is installed

Status in Ubuntu on IBM z Systems:
  New
Status in gcc-12-cross package in Ubuntu:
  New
Status in gcc-13-cross package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == by Stefan  ==
  A simple helloworld program build and linked as static-PIE segfaults while 
startup in __libc_setup_tls:
  $ gcc -c -fPIE -static-pie -o hello.o hello.c
  $ gcc -o hello hello.o -static-pie

  Note:
  If only libc6-dev package is installed, all is fine.
  If both libc6-dev and libc6-dev-s390x-cross packages are installed, you will 
see the mentioned segfault.

  Linking with "-Wl,-v" dumps the used linker command and it shows the used 
startup-files:
  /usr/lib/s390x-linux-gnu/rcrt1.o => from libc6-dev
  /usr/s390x-linux-gnu/lib/crti.o => from libc6-dev-s390x-cross
  /usr/lib/gcc/s390x-linux-gnu/12/crtbeginS.o
  /usr/lib/gcc/s390x-linux-gnu/12/crtendS.o
  /usr/s390x-linux-gnu/lib/crtn.o => from libc6-dev-s390x-cross

  Linking as static-PIE requires the rcrt1.o file, which is not
  available in libc6-dev-s390x-cross package, but in libc6-dev. Due to
  this mixing of the startup-files, you get the segfault.

  This issue can be fixed by enabling static-PIE also in the 
libc6-dev-s390x-cross package, then all startup-files belong to the same 
package. For s390x static-PIE was introduced in glibc 2.36:
  commit "S390: Enable static PIE" (in glibc 2.36)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=728894dba4a19578bd803906de184a8dd51ed13c

  There is a configure check which do a link-test to ensure that a
  suitable binutils(ld) version is used. Afterwards static-PIE is
  automatically enabled. The required binutils-patches are first
  included in binutils 2.39.

  According to the build log of package cross-toolchain-base (see 
https://launchpad.net/ubuntu/+source/cross-toolchain-base/66ubuntu3/+build/25689036),
 the libc6-dev-s390x-cross package is cross-build on x86_64 and the mentioned 
configure check fails:
  running configure fragment for sysdeps/s390/s390-64
  checking for s390-specific static PIE requirements... no

  In this cross build, glibc is configured in order to first build the
  crt-startup-files, which are needed to complete the cross-gcc build.
  At this time, the sysroot does not contain the crt-files or libc.so
  itself. Thus the "linking" configure check is failing. After building
  the cross-gcc, glibc is build without re-configuring. Thus static-PIE
  is not enabled.

  In glibc-upstream, this configure check is now adjusted and it allows 
checking binutils by version number:
  commit "s390x: Fix static PIE condition for toolchain bootstrapping." (will 
be in glibc 2.39)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5f96b784beb3480e0e8d10e250ca7e6063ab881

  Perhaps you also have to pick the following commits by Sam James which 
adjusted the tests in between (both are in glibc 2.36):
  - commit "s390: use $READELF"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=c376ff3287b9b0f78a4f8951313c6dae60cbdfea
  - commit "s390: use LC_ALL=C for readelf call"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2249ec60a987f9a7aa585890de2bd365b3656d28


  In addition to the static-PIE configure-checks, there are those other 
s390-specific configure-checks to determine which IFUNC-optimizations can be 
build and used as default. Those also fail for libc6-dev-s390x-cross as linking 
is also involved:
  running configure fragment for sysdeps/s390
  checking for __builtin_tbegin... yes
  checking for S390 vector instruction support... no
  configure: WARNING: Use binutils with vector-support in order to use 
optimized implementations.
  checking for S390 vector support in gcc... no
  checking for S390 arch13 zarch instruction support... no
  checking for S390 z10 zarch instruction support as default... no
  checking for S390 z196 zarch instruction support as default... no
  checking for S390 z13 zarch instruction support as default... no
  checking for S390 arch13 zarch instruction support as default... no

  Those checks were also adjusted in glibc-upstream. Please also pick this 
commits:
  commit "S390: Use compile-only instead of also link-tests in configure." (in 
glibc 2.38)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=368b7c614b102122b86af3953daea2b30230d0a8

  I've observed this issue on Ubuntu 23.04 with glibc 2.37 and binutils 2.40:
  binutils/lunar-updates,lunar-security,now 2.40-2ubuntu4.1 s390x [installed]
  libc6-dev-s390x-cross/lunar,now 2.37-0ubuntu2cross1 all [installed]
  libc6-dev/lunar,now 2.37-0ubuntu2 s390x 

[Kernel-packages] [Bug 2049924] Re: WireGuard broken on Noble ppc64el

2024-01-31 Thread bugproxy
** Tags added: architecture-ppc64le bugnameltc-205066 severity-medium
targetmilestone-inin---

-- 
You 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:
  Invalid
Status in linux source package in Noble:
  New
Status in netplan.io source package in Noble:
  Invalid

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 2042363] Comment bridged from LTC Bugzilla

2024-01-30 Thread bugproxy
--- Comment From cha...@us.ibm.com 2024-01-30 16:28 EDT---
Is there an update from Canonical please? Can we provide any further 
information or trace to help diagnose this issue ?

-- 
You 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 2038583] Comment bridged from LTC Bugzilla

2024-01-17 Thread bugproxy
--- Comment From andreas.kreb...@de.ibm.com 2024-01-17 07:24 EDT---
In the development team we agreed on disabling the 32 bit compat syscall layer 
in the kernel for IBM Z with Ubuntu 24.04.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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] [NEW] [UBUNTU 22.04] createrepo_c not working under 22.04.3

2024-01-17 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-204657 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-204657 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 

[Kernel-packages] [Bug 2048919] Comment bridged from LTC Bugzilla

2024-01-16 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2024-01-16 05:23 EDT---
@Canonical: Thanks a lot, especially to Frank and the kernel team for your 
extra effort providing a fixed version instantly. Highly appreciated!

-- 
You 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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore

2024-01-16 Thread bugproxy
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2310

-- 
You 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 2048919] Comment bridged from LTC Bugzilla

2024-01-16 Thread bugproxy
--- Comment From fran...@de.ibm.com 2024-01-16 03:12 EDT---
uvdevice is in linux-image-6.5.0-17-generic

# dpkg --list | grep linux-image
ii  linux-image-6.5.0-17-generic 6.5.0-17.17
 s390xSigned kernel image generic

# uname -r
6.5.0-17-generic

cat /boot/config-$(uname -r) | grep UV_UAPI
CONFIG_S390_UV_UAPI=y

# ls /dev/uv
/dev/uv

-- 
You 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 2048919] Re: [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore

2024-01-16 Thread bugproxy
** Tags removed: verification-needed-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/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

2024-01-12 Thread bugproxy
** 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 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 the kernel
  config option still needs to 

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread bugproxy
** Tags removed: targetmilestone-inin--- verification-done-lunar-linux 
verification-done-mantic-linux
** Tags added: targetmilestone-inin2304

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

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread bugproxy
--- Comment From mjros...@us.ibm.com 2024-01-12 13:06 EDT---
Verified with the kernels in -proposed for both mantic and lunar that zPCI 
interpretation is now enabled and usable.  Thanks!

** Tags removed: verification-needed-lunar-linux verification-needed-
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 

[Kernel-packages] [Bug 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes

2024-01-12 Thread bugproxy
** Tags removed: verification-needed-focal-linux-intel-iotg-5.15 
verification-needed-focal-linux-nvidia-tegra-5.15 
verification-needed-jammy-linux-lowlatency-hwe-6.5 
verification-needed-jammy-linux-nvidia-tegra-igx
** 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/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)
 

[Kernel-packages] [Bug 2048919] Comment bridged from LTC Bugzilla

2024-01-11 Thread bugproxy
I believe that having a kernel in PPA to unblock you is not very
helpful, since yI think you need that kernel signed with the usual
(prod.) signature/key (and not with a test/dev key coming from the PPA).

-- 
You 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] [NEW] [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice anymore

2024-01-10 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-204559 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-204559 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2048919

Title:
  [UBUNTU 23.04] Regression: Ubuntu 23.04/23.10 do not include uvdevice
  anymore

Status in linux package in Ubuntu:
  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/+source/linux/+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 2046439] [NEW] Wrong code execution of s390x code with qemu TCG

2023-12-14 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-204491 severity-high 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-204491 severity-high
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2046439

Title:
  Wrong code execution of s390x code with qemu TCG

Status in linux 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/+source/linux/+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

2023-12-13 Thread bugproxy
** Tags removed: verification-done-focal-linux-gcp-tcpx 
verification-done-jammy-linux verification-done-lunar-linux 
verification-done-mantic-linux verification-needed-focal-linux-gcp-5.15 
verification-needed-jammy-linux-azure-fips 
verification-needed-jammy-linux-gkeop verification-needed-jammy-linux-hwe-6.2 
verification-needed-jammy-linux-hwe-6.5 
verification-needed-jammy-linux-intel-iotg 
verification-needed-jammy-linux-lowlatency 
verification-needed-jammy-linux-lowlatency-hwe-6.2 
verification-needed-jammy-linux-nvidia-6.5 
verification-needed-jammy-linux-nvidia-tegra 
verification-needed-lunar-linux-aws verification-needed-lunar-linux-azure 
verification-needed-lunar-linux-gcp verification-needed-lunar-linux-kvm 
verification-needed-lunar-linux-riscv verification-needed-lunar-linux-starfive 
verification-needed-mantic-linux-azure verification-needed-mantic-linux-gcp 
verification-needed-mantic-linux-laptop
** 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/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 Released
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
   

[Kernel-packages] [Bug 2042363] Trace of NFSv4 server

2023-12-06 Thread bugproxy
--- Comment on attachment From jrum...@uk.ibm.com 2023-12-06 04:38 
EDT---


AIX NFS client returns ESTALE at approximately 11:17:24.

** Attachment added: "Trace of NFSv4 server"
   
https://bugs.launchpad.net/bugs/2042363/+attachment/5726664/+files/syslog_amaliada_trace_nfsv4_debug.zip

-- 
You 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 2038583] Comment bridged from LTC Bugzilla

2023-11-30 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2023-11-30 06:45 EDT---
Hi @Dimitri & @Frank,
yes, it does make sense to address the year 2038 time problem rather earlier 
than later - especially since there is an LTS release coming up that will be 
around for 10 or even more years.
We are also in favor of fixing this with noble.
Therefore, we are currently evaluating the solution suggested by Dimitri:  ".. 
we would drop all s390 (31 bit) binaries from Ubuntu, and turn off COMPAT / 
COMPAT_32BIT_TIME in the kernel."

I will post an update as soon as I have double-checked with all affected
parties on our side.

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


[Kernel-packages] [Bug 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes

2023-11-28 Thread bugproxy
** 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/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 could cause other calculation 

[Kernel-packages] [Bug 2039575] Comment bridged from LTC Bugzilla

2023-11-28 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2023-11-28 08:14 EDT---
Thanks you @Wenjia for successfully verifying that the updated kernels in 
-proposed for jammy, lunar and mantic solve the problem.

With that, we can change / add the tags accordingly to:
verification-done-jammy
verification-done-lunar
verification-done-mantic

Thanks everyone for all your work.

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

[Kernel-packages] [Bug 2032247] Comment bridged from LTC Bugzilla

2023-11-27 Thread bugproxy
--- Comment From s...@de.ibm.com 2023-11-27 04:25 EDT---
I've just upgraded to mantic (23.10) and I still see that linking static PIE 
programs leads to a segfaults at runtime.
As mentioned in the bug-report, if both libc6-dev and libc6-dev-s390x-cross 
packages are installed, the crt-object files from the cross package are 
prefered and as the cross package still lacks rcrt1.o (needed for static PIE), 
it just uses it from the non-cross package. Due to the mixture of crt-files, it 
ends up in the segfault at runtime.

Here is the list of my installed libc6-packages:
# apt list --installed "libc6*"
Listing... Done
libc6-dbg/mantic,now 2.38-1ubuntu6 s390x [installed]
libc6-dev-s390/mantic,now 2.38-1ubuntu6 s390x [installed]
libc6-dev-s390x-cross/mantic,now 2.38-1ubuntu4cross1 all [installed]
libc6-dev/mantic,now 2.38-1ubuntu6 s390x [installed]
libc6-s390/mantic,now 2.38-1ubuntu6 s390x [installed]
libc6-s390x-cross/mantic,now 2.38-1ubuntu4cross1 all [installed,automatic]
libc6/mantic,now 2.38-1ubuntu6 s390x [installed]

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

Title:
  [UBUNTU 23.04] S390: static-PIE programs segfaults if
  libc6-dev-s390x-cross package is installed

Status in Ubuntu on IBM z Systems:
  New
Status in gcc-12-cross package in Ubuntu:
  New
Status in gcc-13-cross package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == by Stefan  ==
  A simple helloworld program build and linked as static-PIE segfaults while 
startup in __libc_setup_tls:
  $ gcc -c -fPIE -static-pie -o hello.o hello.c
  $ gcc -o hello hello.o -static-pie

  Note:
  If only libc6-dev package is installed, all is fine.
  If both libc6-dev and libc6-dev-s390x-cross packages are installed, you will 
see the mentioned segfault.

  Linking with "-Wl,-v" dumps the used linker command and it shows the used 
startup-files:
  /usr/lib/s390x-linux-gnu/rcrt1.o => from libc6-dev
  /usr/s390x-linux-gnu/lib/crti.o => from libc6-dev-s390x-cross
  /usr/lib/gcc/s390x-linux-gnu/12/crtbeginS.o
  /usr/lib/gcc/s390x-linux-gnu/12/crtendS.o
  /usr/s390x-linux-gnu/lib/crtn.o => from libc6-dev-s390x-cross

  Linking as static-PIE requires the rcrt1.o file, which is not
  available in libc6-dev-s390x-cross package, but in libc6-dev. Due to
  this mixing of the startup-files, you get the segfault.

  This issue can be fixed by enabling static-PIE also in the 
libc6-dev-s390x-cross package, then all startup-files belong to the same 
package. For s390x static-PIE was introduced in glibc 2.36:
  commit "S390: Enable static PIE" (in glibc 2.36)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=728894dba4a19578bd803906de184a8dd51ed13c

  There is a configure check which do a link-test to ensure that a
  suitable binutils(ld) version is used. Afterwards static-PIE is
  automatically enabled. The required binutils-patches are first
  included in binutils 2.39.

  According to the build log of package cross-toolchain-base (see 
https://launchpad.net/ubuntu/+source/cross-toolchain-base/66ubuntu3/+build/25689036),
 the libc6-dev-s390x-cross package is cross-build on x86_64 and the mentioned 
configure check fails:
  running configure fragment for sysdeps/s390/s390-64
  checking for s390-specific static PIE requirements... no

  In this cross build, glibc is configured in order to first build the
  crt-startup-files, which are needed to complete the cross-gcc build.
  At this time, the sysroot does not contain the crt-files or libc.so
  itself. Thus the "linking" configure check is failing. After building
  the cross-gcc, glibc is build without re-configuring. Thus static-PIE
  is not enabled.

  In glibc-upstream, this configure check is now adjusted and it allows 
checking binutils by version number:
  commit "s390x: Fix static PIE condition for toolchain bootstrapping." (will 
be in glibc 2.39)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5f96b784beb3480e0e8d10e250ca7e6063ab881

  Perhaps you also have to pick the following commits by Sam James which 
adjusted the tests in between (both are in glibc 2.36):
  - commit "s390: use $READELF"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=c376ff3287b9b0f78a4f8951313c6dae60cbdfea
  - commit "s390: use LC_ALL=C for readelf call"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2249ec60a987f9a7aa585890de2bd365b3656d28


  In addition to the static-PIE configure-checks, there are those other 
s390-specific configure-checks to determine which IFUNC-optimizations can be 
build and used as default. Those also fail for libc6-dev-s390x-cross as linking 
is also involved:
  running configure fragment for sysdeps/s390
  checking for __builtin_tbegin... yes
  checking for S390 vector instruction support... no
  configure: WARNING: Use binutils with vector-support in order to use 
optimized 

[Kernel-packages] [Bug 2038587] Comment bridged from LTC Bugzilla

2023-11-21 Thread bugproxy
--- Comment From eller...@au1.ibm.com 2023-11-21 19:17 EDT---
IMO you should just follow the Kconfig dependencies.

ie. if you enable COMPAT then you should also enable COMPAT_32BIT_TIME.

-- 
You 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:
  Incomplete
Status in linux package in Ubuntu:
  Incomplete

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 2044104] [NEW] [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set

2023-11-21 Thread bugproxy
Public bug reported:

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 being copied to the initrd [1].

Unfortunately there is another Ubuntu-initrd script [2] that simply copies ALL
udev rules, including those created by zdev, into the initrd. As a result,
zdev's early-attribute handling is rendered useless and all devices are enabled,
even if a user specified zdev:early=0.

Since this bug report indicates that there is a use-case for this function in
Ubuntu, it might be worth asking Canonical if current processing could be
changed to provide a way for users to specify that a device should specifically
NOT be enabled within initrd processing.

Technically this could easily be done:

1) Have the generic udev initramfs script not copy zdev-generated Udev rules,
   OR
   have the zdev initramfs script remove those rules (somewhat of 

[Kernel-packages] [Bug 2042363] Comment bridged from LTC Bugzilla

2023-11-14 Thread bugproxy
--- Comment From david_pa...@uk.ibm.com 2023-11-14 05:51 EDT---
Ok,
I will arrange for an update/upgrade to the latest kernel in the next week or 
so and turn on those rpcdebug settings when testing the issue. Thanks

-- 
You 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 2032247] Comment bridged from LTC Bugzilla

2023-11-14 Thread bugproxy
--- Comment From s...@de.ibm.com 2023-11-14 04:02 EDT---
Hi doko,
are there any news regarding the cross packages?

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

Title:
  [UBUNTU 23.04] S390: static-PIE programs segfaults if
  libc6-dev-s390x-cross package is installed

Status in Ubuntu on IBM z Systems:
  New
Status in gcc-12 package in Ubuntu:
  New
Status in gcc-13 package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  == by Stefan  ==
  A simple helloworld program build and linked as static-PIE segfaults while 
startup in __libc_setup_tls:
  $ gcc -c -fPIE -static-pie -o hello.o hello.c
  $ gcc -o hello hello.o -static-pie

  Note:
  If only libc6-dev package is installed, all is fine.
  If both libc6-dev and libc6-dev-s390x-cross packages are installed, you will 
see the mentioned segfault.

  Linking with "-Wl,-v" dumps the used linker command and it shows the used 
startup-files:
  /usr/lib/s390x-linux-gnu/rcrt1.o => from libc6-dev
  /usr/s390x-linux-gnu/lib/crti.o => from libc6-dev-s390x-cross
  /usr/lib/gcc/s390x-linux-gnu/12/crtbeginS.o
  /usr/lib/gcc/s390x-linux-gnu/12/crtendS.o
  /usr/s390x-linux-gnu/lib/crtn.o => from libc6-dev-s390x-cross

  Linking as static-PIE requires the rcrt1.o file, which is not
  available in libc6-dev-s390x-cross package, but in libc6-dev. Due to
  this mixing of the startup-files, you get the segfault.

  This issue can be fixed by enabling static-PIE also in the 
libc6-dev-s390x-cross package, then all startup-files belong to the same 
package. For s390x static-PIE was introduced in glibc 2.36:
  commit "S390: Enable static PIE" (in glibc 2.36)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=728894dba4a19578bd803906de184a8dd51ed13c

  There is a configure check which do a link-test to ensure that a
  suitable binutils(ld) version is used. Afterwards static-PIE is
  automatically enabled. The required binutils-patches are first
  included in binutils 2.39.

  According to the build log of package cross-toolchain-base (see 
https://launchpad.net/ubuntu/+source/cross-toolchain-base/66ubuntu3/+build/25689036),
 the libc6-dev-s390x-cross package is cross-build on x86_64 and the mentioned 
configure check fails:
  running configure fragment for sysdeps/s390/s390-64
  checking for s390-specific static PIE requirements... no

  In this cross build, glibc is configured in order to first build the
  crt-startup-files, which are needed to complete the cross-gcc build.
  At this time, the sysroot does not contain the crt-files or libc.so
  itself. Thus the "linking" configure check is failing. After building
  the cross-gcc, glibc is build without re-configuring. Thus static-PIE
  is not enabled.

  In glibc-upstream, this configure check is now adjusted and it allows 
checking binutils by version number:
  commit "s390x: Fix static PIE condition for toolchain bootstrapping." (will 
be in glibc 2.39)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5f96b784beb3480e0e8d10e250ca7e6063ab881

  Perhaps you also have to pick the following commits by Sam James which 
adjusted the tests in between (both are in glibc 2.36):
  - commit "s390: use $READELF"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=c376ff3287b9b0f78a4f8951313c6dae60cbdfea
  - commit "s390: use LC_ALL=C for readelf call"
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=2249ec60a987f9a7aa585890de2bd365b3656d28


  In addition to the static-PIE configure-checks, there are those other 
s390-specific configure-checks to determine which IFUNC-optimizations can be 
build and used as default. Those also fail for libc6-dev-s390x-cross as linking 
is also involved:
  running configure fragment for sysdeps/s390
  checking for __builtin_tbegin... yes
  checking for S390 vector instruction support... no
  configure: WARNING: Use binutils with vector-support in order to use 
optimized implementations.
  checking for S390 vector support in gcc... no
  checking for S390 arch13 zarch instruction support... no
  checking for S390 z10 zarch instruction support as default... no
  checking for S390 z196 zarch instruction support as default... no
  checking for S390 z13 zarch instruction support as default... no
  checking for S390 arch13 zarch instruction support as default... no

  Those checks were also adjusted in glibc-upstream. Please also pick this 
commits:
  commit "S390: Use compile-only instead of also link-tests in configure." (in 
glibc 2.38)
  
https://sourceware.org/git/?p=glibc.git;a=commit;h=368b7c614b102122b86af3953daea2b30230d0a8

  I've observed this issue on Ubuntu 23.04 with glibc 2.37 and binutils 2.40:
  binutils/lunar-updates,lunar-security,now 2.40-2ubuntu4.1 s390x [installed]
  libc6-dev-s390x-cross/lunar,now 2.37-0ubuntu2cross1 all [installed]
  libc6-dev/lunar,now 2.37-0ubuntu2 s390x [installed]
  libc6-s390x-cross/lunar,now 

[Kernel-packages] [Bug 2042885] Re: [UBUNTU 22.04] Running smartctl on NVME hit segmentation fault

2023-11-06 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2023-11-06 19:32 EDT---
--- Comment from Niklas S. ---
This is almost certainly the same problem as described in this upstream issue:
https://github.com/smartmontools/smartmontools/issues/172
"On Big-Endian systems smartctl -a /dev/nvmeXnY may segfault in 
nvme_read_error_log()"

** Bug watch added: github.com/smartmontools/smartmontools/issues #172
   https://github.com/smartmontools/smartmontools/issues/172

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

Title:
  [UBUNTU 22.04] Running smartctl on NVME hit segmentation fault

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - SCHAYNE BELLROSE  - 2023-10-31 
10:08:10 ==
  ---Problem Description---
  Ran sudo smartctl -i -a /dev/nvme0 against NVME drive to get SMART data but 
hit Segmentation fault
   
  Contact Information = Schayne Bellrose/schayne.bellro...@ibm.com 
   
  ---Additional Hardware Info---
  DPM system and added Storage group contains a NVME drive set for data.  

   
  ---uname output---
  Linux t249sb2 5.15.0-87-generic #97-Ubuntu SMP Mon Oct 2 21:11:23 UTC 2023 
s390x s390x s390x GNU/Linux
   
  Machine Type = 3932 
   
  ---Steps to Reproduce---
   Run the following command 
  smartctl -i -a /dev/nvme0 
   
  *Additional Instructions for Schayne Bellrose/schayne.bellro...@ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2042885/+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 2042885] [NEW] [UBUNTU 22.04] Running smartctl on NVME hit segmentation fault

2023-11-06 Thread bugproxy
Public bug reported:

== Comment: #0 - SCHAYNE BELLROSE  - 2023-10-31 
10:08:10 ==
---Problem Description---
Ran sudo smartctl -i -a /dev/nvme0 against NVME drive to get SMART data but hit 
Segmentation fault
 
Contact Information = Schayne Bellrose/schayne.bellro...@ibm.com 
 
---Additional Hardware Info---
DPM system and added Storage group contains a NVME drive set for data.  

 
---uname output---
Linux t249sb2 5.15.0-87-generic #97-Ubuntu SMP Mon Oct 2 21:11:23 UTC 2023 
s390x s390x s390x GNU/Linux
 
Machine Type = 3932 
 
---Steps to Reproduce---
 Run the following command 
smartctl -i -a /dev/nvme0 
 
*Additional Instructions for Schayne Bellrose/schayne.bellro...@ibm.com: 
-Post a private note with access information to the machine that the bug is 
occuring on.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-203947 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-203947 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2042885

Title:
  [UBUNTU 22.04] Running smartctl on NVME hit segmentation fault

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - SCHAYNE BELLROSE  - 2023-10-31 
10:08:10 ==
  ---Problem Description---
  Ran sudo smartctl -i -a /dev/nvme0 against NVME drive to get SMART data but 
hit Segmentation fault
   
  Contact Information = Schayne Bellrose/schayne.bellro...@ibm.com 
   
  ---Additional Hardware Info---
  DPM system and added Storage group contains a NVME drive set for data.  

   
  ---uname output---
  Linux t249sb2 5.15.0-87-generic #97-Ubuntu SMP Mon Oct 2 21:11:23 UTC 2023 
s390x s390x s390x GNU/Linux
   
  Machine Type = 3932 
   
  ---Steps to Reproduce---
   Run the following command 
  smartctl -i -a /dev/nvme0 
   
  *Additional Instructions for Schayne Bellrose/schayne.bellro...@ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2042885/+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] [NEW] [UBUNTU 23.04] Kernel config option missing for s390 PCI passthrough

2023-11-06 Thread bugproxy
Public bug reported:

=== 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 config
option still needs to be enabled.  Comparison from git.launchpad.net:

Jammy:
cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'y'}>
CONFIG_VFIO_PCI_ZDEV_KVMnote<'LP#1853306 Enable VFIO 
zPCI pass-through for s390x'>

Lunar:
cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'n'}>

Mantic:
cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'n'}>

This setting is supposed to default y when S390 && KVM via Kconfig.  Can
this be enabled for lunar, mantic, and future releases?

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-203971 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-203971 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390 PCI passthrough

Status in linux package in Ubuntu:
  New

Bug description:
  === 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
  config option still needs to be enabled.  Comparison from
  git.launchpad.net:

  Jammy:
  cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
  CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'y'}>
  CONFIG_VFIO_PCI_ZDEV_KVMnote<'LP#1853306 Enable VFIO 
zPCI pass-through for s390x'>

  Lunar:
  cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
  CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'n'}>

  Mantic:
  cat debian.master/config/annotations | grep CONFIG_VFIO_PCI_ZDEV_KVM
  CONFIG_VFIO_PCI_ZDEV_KVMpolicy<{'s390x': 'n'}>

  This setting is supposed to default y when S390 && KVM via Kconfig.
  Can this be enabled for lunar, mantic, and future releases?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2042853/+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 2042677] [NEW] [UBUNTU 23.04] PKCS#11 Applications fail to find libopencryptoki.so library due to missing /etc/ld.so.conf.d entry.

2023-11-03 Thread bugproxy
Public bug reported:

--- Problem Description by Grgo M.@IBM ---
PKCS#11 Applications fail to find libopencryptoki.so library due to missing 
/etc/ld.so.conf.d entry.
 
---uname output---
Linux SYSTEM 6.2.0-34-generic #34-Ubuntu SMP Mon Sep  4 12:26:49 UTC 2023 s390x 
s390x s390x GNU/Linux
 
Machine Type = Manufacturer: IBM Type: 3931  Model: 
   704  A01 Sequence Code:00065DC8 
 

---Steps to Reproduce---
Use any application which uses dlopen interface to load libopencryptoki.so 
library.
e.g. build opencryptoki testcases manually from official opencryptoki sources.

# git clone https://github.com/opencryptoki/opencryptoki
# cd opencryptoki
# ./bootstrap.sh
# ./configure --enable-testcases
# make
# ./testcases/crypto/ec_tests -slot 0
 
Userspace tool common name: opencryptoki 3.20.0+dfsg-0ubuntu1.1 
 
The userspace tool has the following bit modes: 64bit 

Userspace rpm: opencryptoki

Userspace tool obtained from project website:  na

== Comment: #2  - 2023-11-03 04:24:48 ==
Opencryptoki generates an appropriate ld.so.conf.d entry 
/etc/ld.so.conf.d/opencryptoki-$(target_cpu).conf during 'make install'. 
Ubuntu should include this into its package to allow applications to find the 
libopencryptoki.so library when using dlopen().

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-203847 severity-high 
targetmilestone-inin2304

** Tags added: architecture-s39064 bugnameltc-203847 severity-high
targetmilestone-inin2304

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/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 linux package in Ubuntu:
  New

Bug description:
  --- Problem Description by Grgo M.@IBM ---
  PKCS#11 Applications fail to find libopencryptoki.so library due to missing 
/etc/ld.so.conf.d entry.
   
  ---uname output---
  Linux SYSTEM 6.2.0-34-generic #34-Ubuntu SMP Mon Sep  4 12:26:49 UTC 2023 
s390x s390x s390x GNU/Linux
   
  Machine Type = Manufacturer: IBM Type: 3931  Model:   
 704  A01 Sequence Code:00065DC8 
   

  ---Steps to Reproduce---
  Use any application which uses dlopen interface to load libopencryptoki.so 
library.
  e.g. build opencryptoki testcases manually from official opencryptoki sources.

  # git clone https://github.com/opencryptoki/opencryptoki
  # cd opencryptoki
  # ./bootstrap.sh
  # ./configure --enable-testcases
  # make
  # ./testcases/crypto/ec_tests -slot 0
   
  Userspace tool common name: opencryptoki 3.20.0+dfsg-0ubuntu1.1 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: opencryptoki

  Userspace tool obtained from project website:  na

  == Comment: #2  - 2023-11-03 04:24:48 ==
  Opencryptoki generates an appropriate ld.so.conf.d entry 
/etc/ld.so.conf.d/opencryptoki-$(target_cpu).conf during 'make install'. 
  Ubuntu should include this into its package to allow applications to find the 
libopencryptoki.so library when using dlopen().

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

2023-11-02 Thread bugproxy
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2204

-- 
You 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,
   

[Kernel-packages] [Bug 2039575] Re: SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes

2023-11-02 Thread bugproxy
** Tags removed: verification-needed-jammy-linux verification-needed-
lunar-linux verification-needed-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.

   * The bucket (aka pos) 

[Kernel-packages] [Bug 2042363] [NEW] 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 s

2023-10-31 Thread bugproxy
Public bug reported:

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

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New


** Tags: architecture-x8664 bugnameltc-203937 severity-high 
targetmilestone-inin2004

** Tags added: architecture-x8664 bugnameltc-203937 severity-high
targetmilestone-inin2004

** Changed in: ubuntu
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Package changed: ubuntu => linux (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/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 2039783] [NEW] [UBUNTU 23.10] Opencryptoki package instalation not creating /run/opencryptoki directory

2023-10-19 Thread bugproxy
Public bug reported:

---Problem Description  (by Grgo Mariani) ---
Opencryptoki post-installation script fails due to a non-existing directory.
Although the package is shown as installed the missing directory is critical 
for service running.
 
Contact Information = grgo.mari...@ibm.com christian.r...@de.ibm.com 
 
---uname output---
Linux SYSTEM 6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 19:43:35 UTC 2023 s390x 
s390x s390x GNU/Linux
 
Machine Type = Manufacturer: IBM Type: 3931  Model: 
   704  A01 
 
---Debugger---
A debugger is not configured
 
---Steps to Reproduce---
Install the opencryptoki package and check if the service is running.

root@SYSTEM:~# apt install opencryptoki
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  opencryptoki
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 228 kB of archives.
After this operation, 834 kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports mantic/universe s390x opencryptoki 
s390x 3.21.0+dfsg-0ubuntu1 [228 kB]
Fetched 228 kB in 0s (1,130 kB/s)
Selecting previously unselected package opencryptoki.
(Reading database ... 68397 files and directories currently installed.)
Preparing to unpack .../opencryptoki_3.21.0+dfsg-0ubuntu1_s390x.deb ...
Unpacking opencryptoki (3.21.0+dfsg-0ubuntu1) ...
Setting up opencryptoki (3.21.0+dfsg-0ubuntu1) ...
info: The group `pkcs11' already exists as a system group. Exiting.
info: The system user `pkcsslotd' already exists. Exiting.

info: Adding user `root' to group `pkcs11' ...
chown: cannot access '/run/opencryptoki': No such file or directory
dpkg: error processing package opencryptoki (--configure):
 installed opencryptoki package post-installation script subprocess returned 
error exit status 1
Processing triggers for man-db (2.11.2-3) ...
Errors were encountered while processing:
 opencryptoki
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@SYSTEM:~# systemctl status pkcsslotd


 
Userspace tool common name: opencryptoki 
 
The userspace tool has the following bit modes: 64bit 

Userspace rpm: opencryptoki v3.21.0

Userspace tool obtained from project website:  na

== Comment: #1 - Ingo Franzki - 2023-10-18 09:26:50 ==
/run/opencryptoki should be created by the package install, but is also created 
by tmpfiles.d service after every boot, because /run is usually in tempfs, so 
its not persistent across boots. OCK installs a tempfiles.d config script 
(/usr/lib/tmpfiles.d/opencryptoki.conf), too.

== Comment: #3 - Ingo Franzki - 2023-10-18 10:13:30 ==
It also seems that Ubuntu's /usr/lib/tmpfiles.d/opencryptoki.conf file has 
incorrect (outdated?) contents.
It must be ensured that the file as produced by building Opencryptoki (via 
'make install') is installed, and not something else/older.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-203873 severity-high 
targetmilestone-inin2310

** Tags added: architecture-s39064 bugnameltc-203873 severity-high
targetmilestone-inin2310

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2039783

Title:
  [UBUNTU 23.10] Opencryptoki package instalation not creating
  /run/opencryptoki directory

Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description  (by Grgo Mariani) ---
  Opencryptoki post-installation script fails due to a non-existing directory.
  Although the package is shown as installed the missing directory is critical 
for service running.
   
  Contact Information = grgo.mari...@ibm.com christian.r...@de.ibm.com 
   
  ---uname output---
  Linux SYSTEM 6.5.0-9-generic #9-Ubuntu SMP Fri Oct  6 19:43:35 UTC 2023 s390x 
s390x s390x GNU/Linux
   
  Machine Type = Manufacturer: IBM Type: 3931  Model:   
 704  A01 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
  Install the opencryptoki package and check if the service is running.

  root@SYSTEM:~# apt install opencryptoki
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following NEW packages will be installed:
opencryptoki
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 228 kB of archives.
  After this operation, 834 kB of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports mantic/universe s390x opencryptoki 
s390x 3.21.0+dfsg-0ubuntu1 [228 kB]
  Fetched 228 kB in 

[Kernel-packages] [Bug 2019011] Re: [UBUNTU 20.04] [HPS] Kernel panic with "refcount_t: underflow" in mlx5 driver

2023-10-17 Thread bugproxy
** Tags removed: verification-needed-focal-linux-bluefield

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

Title:
  [UBUNTU 20.04] [HPS] Kernel panic with "refcount_t: underflow" in mlx5
  driver

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

Bug description:
  SRU Justification:
  ==

  [ Impact ]

   * The mlx5 driver is causing a Kernel panic with
     "refcount_t: underflow".

   * This issue occurs during a recovery when the PCI device
     is isolated and thus doesn't respond.

  [ Fix ]

   * This issue got solved upstream with
     aaf2e65cac7f aaf2e65cac7f2e1ae729c2fbc849091df9699f96
     "net/mlx5: Fix handling of entry refcount when command
     is not issued to FW" (upstream since 6.1-rc1)

   * But to get aaf2e65cac7f a backport of b898ce7bccf1
     b898ce7bccf13087719c021d829dab607c175246
     "net/mlx5: cmdif, Avoid skipping reclaim pages if FW is
     not accessible" is required on top (upstream since 5.10)

  [ Test Plan ]

   * An Ubuntu Server for s390x 20.04 LPAR or z/VM installation
     is needed that has Mellanox cards (RoCE Express 2.1)
     assigned, configured and enabled and that runs a 5.4
     kernel with mlx5 driver.

   * Create some network traffic on (one of the) RoCE device
     (interface ens???[d?]) for testing (e.g. with stress-ng).

   * Make sure the module/driver mlx5 is loaded and in use.

   * Trigger a recovery (via the Support Element)
     that will render the adapter (ports) unresponsive
     for a moment and should provoke a similar situation.

   * Alternatively the interface itself can be removed for
     a moment and re-added again (but this may break further
     things on top).

   * Due to the lack of RoCE Express 2.1 hardware,
     the verification is on IBM.

  [ Where problems could occur ]

   * The modifications are limited to the Mellanox mlx5 driver
     only - no other network driver is affected.

   * The pre-required commit (aaf2e65cac7f) can have a bad
     impact on (re-)claiming pages if FW is not accessible,
     which could cause page leaks in case done wrong.
     But this commit is pretty save since it's upstream
     since v5.10.

   * The fix itself (aaf2e65cac7f) mainly changes the
     cmd_work_handler and mlx5_cmd_comp_handler functions
     in a way that instead of pci_channel_offline
     mlx5_cmd_is_down (introiduced by b898ce7bccf1).

   * Actually b898ce7bccf1 started with changing from
     pci_channel_offline to mlx5_cmd_is_down,
     but looks like a few cases
     (in the area of refcount increate/decrease) were missed,
     that are now covered by aaf2e65cac7f.

   * It fixes now on top refcounts are now always properly
     increment and decrement to achieve a symmetric state
     for all flows.

   * These changes may have an impact on all cases where the
     mlx5 device is not responding, which can happen in case
     of an offline channel, interface down, reset or recovery.

  [ Other Info ]

   * Looking at the master-next git trees for jammy, kinetic
     and lunar showed that both fixes are already included,
     hence only focal is affected.
  __

  ---Problem Description---

  Kernel panic with "refcount_t: underflow" in kernel log

  Contact Information = rijo...@ibm.com, vineeth.vija...@ibm.com

  ---uname output---
  5.4.0-128-generic

  Machine Type = s390x

  ---System Hang---
  Kernel panic and stack-trace as below

  ---Debugger---
  A debugger is not configured

  Stack trace output:
  [Sat Apr  8 17:52:21 UTC 2023] Call Trace:
  [Sat Apr  8 17:52:21 UTC 2023] ([<002a5939a286>] 
refcount_warn_saturate+0xce/0x140)
  [Sat Apr  8 17:52:21 UTC 2023]  [<03ff805f861e>] cmd_ent_put+0xe6/0xf8 
[mlx5_core]
  [Sat Apr  8 17:52:21 UTC 2023]  [<03ff805f9b6a>] 
mlx5_cmd_comp_handler+0x102/0x4f0 [mlx5_core]
  [Sat Apr  8 17:52:21 UTC 2023]  [<03ff805f9f8a>] 
cmd_comp_notifier+0x32/0x48 [mlx5_core]
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58ecf0c6>] 
notifier_call_chain+0x4e/0xa0
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58ecf17e>] 
atomic_notifier_call_chain+0x2e/0x40
  [Sat Apr  8 17:52:21 UTC 2023]  [<03ff805fe4fc>] 
mlx5_eq_async_int+0x13c/0x200 [mlx5_core]
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58ecf0c6>] 
notifier_call_chain+0x4e/0xa0
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58ecf17e>] 
atomic_notifier_call_chain+0x2e/0x40
  [Sat Apr  8 17:52:21 UTC 2023]  [<03ff8061318e>] 
mlx5_irq_int_handler+0x2e/0x48 [mlx5_core]
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58f1455a>] 
__handle_irq_event_percpu+0x6a/0x250
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58f14770>] 
handle_irq_event_percpu+0x30/0x78
  [Sat Apr  8 17:52:21 UTC 2023]  [<002a58f1a0c8>] 
handle_percpu_irq+0x68/0xa0
  [Sat Apr  8 17:52:21 UTC 2023]  

[Kernel-packages] [Bug 2039575] Comment bridged from LTC Bugzilla

2023-10-17 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2023-10-17 10:31 EDT---
There is a fix available (thanks Wenjia) to address this problem which occurs 
with kernel 5.14 and above:

The fix patch "a950a5921db4 (net/smc: Fix pos miscalculation in
statistics)" is already upstream

--- Comment From boris.m...@de.ibm.com 2023-10-17 10:33 EDT---
FYI: This fix also resolves the UBSAN array-index-out-of-bounds issue mentioned 
by Matthew
during the verification performed as part of IBM BZ 182254 / launchpad 1853306.

-- 
You 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:
  [UBUNTU 22.04] SMC stats: Wrong bucket calculation for payload of
  exactly 4096 bytes.

Status in linux package in Ubuntu:
  New

Bug description:
  Bug description by Nils H.:

  
   Overview: 
  
  The following line in the SMC stats code (net/smc/smc_stats.h) caught my 
attention when using a payload of exactly 4096 bytes:

  #define SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) \
  do { \
typeof(_smc_stats) stats = (_smc_stats); \
typeof(_tech) t = (_tech); \
typeof(_len) l = (_len); \
int _pos = fls64((l) >> 13); \
typeof(_rc) r = (_rc); \
int m = SMC_BUF_MAX - 1; \
this_cpu_inc((*stats).smc[t].key ## _cnt); \
if (r <= 0) \
break; \
_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \  
<---
this_cpu_inc((*stats).smc[t].key ## _pd.buf[_pos]); \
this_cpu_add((*stats).smc[t].key ## _bytes, r); \
  } \
  while (0)

  
  With l = 4096, _pos evaluates to -1.

  
  Checking with the following uperf profile:
  # cat rr1c-4kx4k---1.xml 
  
  



 











  

  
  smcd stats output:
  # 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 conn14.0
TCP fallback  0 (client 0, server 0)

  RX Stats
Data transmitted (Bytes)   5796 (5.796K)
Total requests9
Buffer full   0 (0.00%)
Buffer downgrades 0
Buffer reuses 0
  8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
Bufs0   0   0   2   0   0   0   1
Reqs8   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
  8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
Bufs0   2   0   0   0   0   0   0
Reqs   18   0   0   0   0   0   0   1

  Extras
Special socket calls  0
  cork0
  nodelay 0
  sendpage0
  splice  0
  urgent data 0

  
  Instead of including the payload in the wrong >512KB buckets, output should 
be to have 19 reqs in the 8KB buckets for TX stats and 9 reqs in the 8KB bucket 
for RX stats.


  
   Repro:
  
  0. Install uperf.
  1. Reset SMC-D stats on client and server.
  2. Start uperf at server side: "uperf -vs".
  3. Update profile with remote IP (server IP) and start uperf at client: 
"uperf -vai 5 -m rr1c-4kx4k---1.xml" (uperf profile, see above)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039575/+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] Comment bridged from LTC Bugzilla

2023-10-17 Thread bugproxy
--- Comment From boris.m...@de.ibm.com 2023-10-17 10:23 EDT---
--- MATTHEW R. commented ---

I encountered this issue recently while verifying a KVM feature.  It's
worth noting that if a kernel has UBSAN enabled
(https://docs.kernel.org/dev-tools/ubsan.html) then rather than silently
updating an incorrect stats counter you will also get a UBSAN array-
index-out-of-bounds warning every time this occurs.  In my case, I
bumped into this because I was using an Ubuntu kernel which came with
UBSAN enabled.  Example of the warning:

[   26.335369] 

[   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: GE 
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

This makes the issue much more visible.

Worse, if you have panic_on_warn enabled (like I did) then this warning
will subsequently trigger a kernel panic.

-- 
You 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:
  [UBUNTU 22.04] SMC stats: Wrong bucket calculation for payload of
  exactly 4096 bytes.

Status in linux package in Ubuntu:
  New

Bug description:
  Bug description by Nils H.:

  
   Overview: 
  
  The following line in the SMC stats code (net/smc/smc_stats.h) caught my 
attention when using a payload of exactly 4096 bytes:

  #define SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) \
  do { \
typeof(_smc_stats) stats = (_smc_stats); \
typeof(_tech) t = (_tech); \
typeof(_len) l = (_len); \
int _pos = fls64((l) >> 13); \
typeof(_rc) r = (_rc); \
int m = SMC_BUF_MAX - 1; \
this_cpu_inc((*stats).smc[t].key ## _cnt); \
if (r <= 0) \
break; \
_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \  
<---
this_cpu_inc((*stats).smc[t].key ## _pd.buf[_pos]); \
this_cpu_add((*stats).smc[t].key ## _bytes, r); \
  } \
  while (0)

  
  With l = 4096, _pos evaluates to -1.

  
  Checking with the following uperf profile:
  # cat rr1c-4kx4k---1.xml 
  
  



 











  

  
  smcd stats output:
  # 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 conn14.0
TCP fallback  0 (client 0, server 0)

  RX Stats
Data transmitted (Bytes)   5796 (5.796K)
Total requests9
Buffer full   0 (0.00%)
Buffer downgrades 0
Buffer reuses 0
  8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
Bufs0   0   0   2   0   0   0   1
Reqs8   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
  8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
Bufs0   2   0   0   0   0   0   0
Reqs   18   0   0   0   0   0   0   1

  Extras
Special socket calls  0
  cork

[Kernel-packages] [Bug 2039575] [NEW] [UBUNTU 22.04] SMC stats: Wrong bucket calculation for payload of exactly 4096 bytes.

2023-10-17 Thread bugproxy
Public bug reported:

Bug description by Nils H.:


 Overview: 

The following line in the SMC stats code (net/smc/smc_stats.h) caught my 
attention when using a payload of exactly 4096 bytes:

#define SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) \
do { \
typeof(_smc_stats) stats = (_smc_stats); \
typeof(_tech) t = (_tech); \
typeof(_len) l = (_len); \
int _pos = fls64((l) >> 13); \
typeof(_rc) r = (_rc); \
int m = SMC_BUF_MAX - 1; \
this_cpu_inc((*stats).smc[t].key ## _cnt); \
if (r <= 0) \
break; \
_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \  
<---
this_cpu_inc((*stats).smc[t].key ## _pd.buf[_pos]); \
this_cpu_add((*stats).smc[t].key ## _bytes, r); \
} \
while (0)


With l = 4096, _pos evaluates to -1.


Checking with the following uperf profile:
# cat rr1c-4kx4k---1.xml 





 














smcd stats output:
# 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 conn14.0
  TCP fallback  0 (client 0, server 0)

RX Stats
  Data transmitted (Bytes)   5796 (5.796K)
  Total requests9
  Buffer full   0 (0.00%)
  Buffer downgrades 0
  Buffer reuses 0
8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
  Bufs0   0   0   2   0   0   0   1
  Reqs8   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
8KB16KB32KB64KB   128KB   256KB   512KB  >512KB
  Bufs0   2   0   0   0   0   0   0
  Reqs   18   0   0   0   0   0   0   1

Extras
  Special socket calls  0
cork0
nodelay 0
sendpage0
splice  0
urgent data 0


Instead of including the payload in the wrong >512KB buckets, output should be 
to have 19 reqs in the 8KB buckets for TX stats and 9 reqs in the 8KB bucket 
for RX stats.



 Repro:

0. Install uperf.
1. Reset SMC-D stats on client and server.
2. Start uperf at server side: "uperf -vs".
3. Update profile with remote IP (server IP) and start uperf at client: "uperf 
-vai 5 -m rr1c-4kx4k---1.xml" (uperf profile, see above)

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
 Status: New


** Tags: architecture-s39064 bugnameltc-203868 severity-medium 
targetmilestone-inin---

** Tags added: architecture-s39064 bugnameltc-203868 severity-medium
targetmilestone-inin---

** Changed in: ubuntu
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Package changed: ubuntu => linux (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/2039575

Title:
  [UBUNTU 22.04] SMC stats: Wrong bucket calculation for payload of
  exactly 4096 bytes.

Status in linux package in Ubuntu:
  New

Bug description:
  Bug description by Nils H.:

  
   Overview: 
  
  The following line in the SMC stats code (net/smc/smc_stats.h) caught my 
attention when using a payload of exactly 4096 bytes:

  #define SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) \
  do { \
typeof(_smc_stats) stats = (_smc_stats); \
typeof(_tech) t = (_tech); \
typeof(_len) l = (_len); \
int _pos = fls64((l) >> 13); \
typeof(_rc) r = (_rc); \
int m = SMC_BUF_MAX - 1; \
this_cpu_inc((*stats).smc[t].key ## _cnt); \
if (r <= 0) \
break; \
_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \  
<---
this_cpu_inc((*stats).smc[t].key ## _pd.buf[_pos]); \
this_cpu_add((*stats).smc[t].key ## _bytes, r); \
  } 

[Kernel-packages] [Bug 2038583] Re: Turning COMPAT_32BIT_TIME off on s390x

2023-10-12 Thread bugproxy
** Tags added: architecture-s39064 bugnameltc-203848 severity-medium
targetmilestone-inin---

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


[Kernel-packages] [Bug 2038587] Re: Turning COMPAT_32BIT_TIME off on ppc64el

2023-10-10 Thread bugproxy
** Tags added: architecture-ppc64le bugnameltc-203835 severity-medium
targetmilestone-inin---

-- 
You 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:
  New
Status in linux package in Ubuntu:
  Incomplete

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


  1   2   3   4   5   6   7   8   9   10   >