Add missing ARM-cores to support Grace-based systems

[Joao Andre Simioni]

[Impact]

When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't report a model name:

Vendor ID: ARM
Model: 0

[Fix]

Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. The commit below adds the specific codes missing from Jammy's version.

https://github.com/util-linux/util-linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

[Test Steps]

* Verify whether output of lscpu is correct on new CPUs; eg:
Vendor ID: ARM
Model name: Neoverse-V2

* Verify whether output of lscpu doesn't change on old CPUs; eg:
Vendor ID: ARM
Model name: Neoverse-N1

[What Could Go Wrong]

The fix only introduces additional model identifiers to match
against and print a model name string, thus regression impact
should be contained within lscpu and printing cpus model name
on ARM systems.

Output doesn't change on systems with non-affected CPU models.

[Heather Lemon (hypothetical-lemon)]

creating testing ppa https://launchpad.net/~hypothetical-lemon/+archive/ubuntu/lp2019856-util-linux

[Heather Lemon (hypothetical-lemon)]

adds jammy debdiff

[Heather Lemon (hypothetical-lemon)]

adds lunar debdiff

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp-2019856-add-missing-arm-cores-jammy.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Mauricio Faria de Oliveira (mfo)]

Heather mentioned some changes she has for the debdiffs, I also noted some changes to DEP3 headers, and debdiffs v2 are in progress. Thanks, Heather!

[Heather Lemon (hypothetical-lemon)]

fixed header for patch

[Heather Lemon (hypothetical-lemon)]

v2 fixed lunar header patch

[Mauricio Faria de Oliveira (mfo)]

Hey Heather, thanks for the updated debdiffs!

I've looked at them, and did minor fixes to DEP3
(moved them out of the original commit message,
after `---`, and added Origin: fields), and just
a cosmetic adjustment to the changelog.

It turns out this patch isn't present in Mantic.
I already handled the debdiff/tests; don't worry.
I'll look for a sponsor for the devel release,
and handle the stable releases/SRUs afterward.

I marked Kinetic as won't fix, as it's not needed
and close to EOL anyway.

  $ ubuntu-distro-info --series=kinetic --days=eol
  58

I removed the verification tags you added?
They are added automatically by the SRU machinery
when the packages land in -proposed for testing.

cheers,
Mauricio

[Mauricio Faria de Oliveira (mfo)]

Test packages in ppa:mfo/lp2019856, verified with GDB
(to fake CPU IDs) on Google Cloud ARM-based instances.

No differences in `lscpu` output for non-affected CPU.
Expected output for both affected CPUs (0xd15, 0xd4f).

Tested on LXD containers for Mantic, Lunar, and Jammy
(not on Kinetic as it will EOL soon, ~2 months).

Mantic:
---

$ lxc launch ubuntu-daily:mantic mantic
$ lxc shell mantic

# lsb_release -cs
No LSB modules are available.
mantic

Old:

 # apt install util-linux/mantic-proposed

 # dpkg -s util-linux | grep Version:
 Version: 2.38.1-5ubuntu1

 # lscpu | grep -e 'Vendor ID:' -e 'Model name:'
 Vendor ID: ARM
 Model name: Neoverse-N1

 # lscpu > lscpu.old

Old/GDB:

 # apt install gdb

 # cat >lp2019856-reproducer.gdb <<EOF
 break arm_ids_decode

 run
 p ct.model
 call (void *) memcpy(ct.model, "0xd15", 6)
 p ct.model
 continue

 run
 p ct.model
 call (void *) memcpy(ct.model, "0xd4f", 6)
 p ct.model
 continue

 quit
 EOF

 # export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com"
 # gdb -x lp2019856-reproducer.gdb -iex 'set debuginfod enabled on' lscpu 2>&1 | grep -e '^\$' -e 'Model name:'
 $1 = 0xaaaaaaad8570 "0xd0c"
 $2 = (void *) 0xaaaaaaad8570
 $3 = 0xaaaaaaad8570 "0xd15"
 Model name: -
 $4 = 0xaaaaaaad8570 "0xd0c"
 $5 = (void *) 0xaaaaaaad8570
 $6 = 0xaaaaaaad8570 "0xd4f"
 Model name: -

New:

 # add-apt-repository -y ppa:mfo/lp2019856
 # sed -i '/Components:/ s,$, main/debug,' /etc/apt/sources.list.d/mfo-ubuntu-lp2019856-mantic.sources
 # apt update
 # apt install -y util-linux util-linux-dbgsym

 # dpkg -s util-linux | grep Version:
 Version: 2.38.1-5ubuntu2

 # lscpu | grep -e 'Vendor ID:' -e 'Model name:'
 Vendor ID: ARM
 Model name: Neoverse-N1

 # lscpu > lscpu.new
 # diff lscpu.old lscpu.new
 #

New/GDB:

 # gdb -x lp2019856-reproducer.gdb lscpu 2>&1 | grep -e '^\$' -e 'Model name:'
 $1 = 0xaaaaaaad8570 "0xd0c"
 $2 = (void *) 0xaaaaaaad8570
 $3 = 0xaaaaaaad8570 "0xd15"
 Model name: Cortex-R82
 $4 = 0xaaaaaaad8570 "0xd0c"
 $5 = (void *) 0xaaaaaaad8570
 $6 = 0xaaaaaaad8570 "0xd4f"
 Model name: Neoverse-V2

Lunar
---

$ lxc launch ubuntu:lunar lunar
$ lxc shell lunar

# lsb_release -cs
No LSB modules are available.
lunar

Old:

 # dpkg -s util-linux | grep Version:
 Version: 2.38.1-4ubuntu1

 # lscpu | grep -e 'Vendor ID:' -e 'Model name:'
 Vendor ID: ARM
 Model name: Neoverse-N1

 # lscpu > lscpu.old
 #

Old/GDB:

 # apt install gdb
 # export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com"

 # cat >lp2019856-reproducer.gdb <<EOF
 break arm_ids_decode

 run
 p ct.model
 call (void *) memcpy(ct.model, "0xd15", 6)
 p ct.model
 continue

 run
 p ct.model
 call (void *) memcpy(ct.model, "0xd4f", 6)
 p ct.model
 continue

 quit
 EOF

 # gdb -x lp2019856-reproducer.gdb -iex 'set debuginfod enabled on' lscpu 2>&1 | grep -e '^\$' -e 'Model name:'
 $1 = 0xaaaaaaad8570 "0xd0c"
 $2 = (void *) 0xaaaaaaad8570
 $3 = 0xaaaaaaad8570 "0xd15"
 Model name: -
 $4 = 0xaaaaaaad8570 "0xd0c"
 $5 = (void *) 0...

[Mauricio Faria de Oliveira (mfo)]

Debdiff on top of mantic-proposed (2.38.1-5ubuntu1), which should migrate soon (all good on update-excuses [1] / pending autopkgtests).

https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux

[Mauricio Faria de Oliveira (mfo)]

For Mantic, this indeed requires a patch, not a merge/sync, as Debian doesn't have the commit yet either.

$ git remote get-url origin
git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

$ git describe --contains 6857cccbb4157d5da34ca98f77a0ac9d68e1e740
v2.39-rc1~126^2~4

$ git show v2.39 | grep Date:
Date: Wed May 17 12:27:51 2023 +0200
Date: Wed May 17 11:58:48 2023 +0200

$ rmadison -a source util-linux | grep mantic
 util-linux | 2.38.1-4ubuntu1 | mantic | source
 util-linux | 2.38.1-5ubuntu1 | mantic-proposed | source

$ rmadison -u debian -a source util-linux
...
util-linux | 2.38.1-5 | testing | source
util-linux | 2.38.1-5 | unstable | source
util-linux | 2.38.1-5 | unstable-debug | source

[Mauricio Faria de Oliveira (mfo)]

util-linux 2.38.1-5ubuntu1 finally migrated from mantic-proposed to mantic
(its autopkgtests were very slow/cycling last week, apparently).

I'll check for potential sponsors to the debdiff in comment #10.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp-2019856-add-missing-arm-cores-jammy.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Dan Bungert (dbungert)]

Uploaded for Mantic, thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package util-linux - 2.38.1-5ubuntu2

---------------
util-linux (2.38.1-5ubuntu2) mantic; urgency=medium

  * d/p/ubuntu/lp-2019856-add-missing-arm-cores.patch:
    Add missing ARM cores for NVIDIA Grace (LP: #2019856)

 -- Mauricio Faria de Oliveira <email address hidden> Tue, 23 May 2023 15:55:47 -0300

[Mauricio Faria de Oliveira (mfo)]

Uploaded to Lunar and Jammy, but not Kinetic (Won't Fix).

$ ubuntu-distro-info --series=kinetic --days=eol
45

Thanks!

[Steve Langasek (vorlon)]

This looks low risk, but also low impact (how important is it to have the correct model name output in lscpu?) in a core package installed on all users' systems. I'm fine with the idea of such a change being included in an SRU, but I think we wouldn't normally push an SRU *just* for a change such as this.

I would be ok with this being tagged block-proposed to keep it in -proposed until another high-impact change comes along, or having it bundled now with other high-impact fixes if there are any. Does that sound appropriate to you?

[Robie Basak (racb)]

I was about to ask *why* Ubuntu users need this change before I read Steve's comment. It might be helpful to expand on that, because without a full explanation, we (SRU team) are only really _speculating_ on the actual user impact.

[Steve Langasek (vorlon)]

Mauricio, this SRU is still waiting for an answer to https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/comments/17

[Joao Andre Simioni (jasimioni)]

Steve,

We got the okay from the user to hold this until we have another high-impact change. It'd be interesting to set a time frame - if we don't have any of those happening in, let's say, 6 months, would it be fair to re-consider the SRU?

Thanks

[Mauricio Faria de Oliveira (mfo)]

Steve / #17,

Sorry, this was discussed internally at the time, but for some reason the answers didn't make it here back then.

If we get another bug (e.g., another simple change from existing util-linux bugs, that still makes sense to be SRUed) that can be combined with this SRU, would that be good to go?

Thanks,
Mauricio

[Julian Andres Klode (juliank)]

The approach to take would be to add a block-proposed-jammy tag and then the SRU can be processed and it will just say in proposed until another SRU gets along that replaces (and includes) it, but at least it's built and reviewed and visible to everyone.

[Steve Langasek (vorlon)]

Thanks, I will mark these SRUs as block-proposed-$release and accept them now.

> It'd be interesting to set a time frame - if we don't have any of those
> happening in, let's say, 6 months, would it be fair to re-consider the SRU?

In my view this would still not be an SRU that should be released on its own; staged SRU changes do not have a time limit.

[Steve Langasek (vorlon)]

Hello Joao, or anyone else affected,

Accepted util-linux into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.38.1-4ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Joao, or anyone else affected,

Accepted util-linux into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.37.2-4ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted util-linux (2.38.1-4ubuntu1.1) for lunar have finished running.
The following regressions have been reported in tests triggered by the package:

glib2.0/2.76.1-1 (armhf)
rsyslog/8.2302.0-1ubuntu3 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/lunar/update_excuses.html#util-linux

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted util-linux (2.37.2-4ubuntu3.1) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

cluster-glue/1.0.12-20ubuntu3 (ppc64el)
cmake-extras/1.6-1 (armhf)
kopanocore/8.7.0-7.1ubuntu10 (amd64)
netplan.io/0.105-0ubuntu2~22.04.3 (arm64, armhf, s390x)
node-mqtt/4.2.8-1 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#util-linux

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Mauricio Faria de Oliveira (mfo)]

The autopkgtests failures in lunar seem to be a kernel issue during the initialization of the virtio rng driver, when the mutex for (generic/core) hw rng is acquired (apparently something else is holding it indefinitely, thus the blocked task warnings show up, and it seems the VM doesn't proceed to the point of being detected, and the test fails/times out).

I haven't seen related commits listed in the later linux package changelogs for lunar (this is with 6.2.0-25-generic), nor could reproduce this in a LXD VM with the same version (it uses a virtio rng device too).

Let's try again when another openstack image for lunar is available (current/failing is 2023-07-17).

[Mauricio Faria de Oliveira (mfo)]

The autopkgtests failures in jammy seem to be of various sorts, but are not expected to be related to this code change at all. I've skimmed through them, and some seemed worth of retries (timeouts, network issues, etc).

[Mauricio Faria de Oliveira (mfo)]

All autopkgtests have now passed (lunar/jammy).

https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#util-linux
https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html#util-linux

[Joao Andre Simioni (jasimioni)]

Tests complete in Jammy:

$ apt policy util-linux
util-linux:
Installed: 2.37.2-4ubuntu3.1
Candidate: 2.37.2-4ubuntu3.1
Version table:
*** 2.37.2-4ubuntu3.1 500
500 http://ports.ubuntu.com/ubuntu-ports jammy-proposed/main arm64 Packages
100 /var/lib/dpkg/status
2.37.2-4ubuntu3 500
500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
$ lscpu | head -n 10
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 291
On-line CPU(s) list: 0-290
Vendor ID: ARM
Model name: Neoverse-V2
Model: 0
Thread(s) per core: 1
Core(s) per socket: 72

[Joao Andre Simioni (jasimioni)]

Tests complete in Lunar:

root@9a692adeec83:/# apt policy util-linux
util-linux:
Installed: 2.38.1-4ubuntu1
Candidate: 2.38.1-4ubuntu1
Version table:
2.38.1-4ubuntu1.1 100
100 http://ports.ubuntu.com/ubuntu-ports lunar-proposed/main arm64 Packages
*** 2.38.1-4ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports lunar/main arm64 Packages
100 /var/lib/dpkg/status
root@9a692adeec83:/# apt install util-linux=2.38.1-4ubuntu1.1 -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
dosfstools kbd util-linux-locales
The following packages will be upgraded:
util-linux
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1074 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports lunar-proposed/main arm64 util-linux arm64 2.38.1-4ubuntu1.1 [1074 kB]
Fetched 1074 kB in 1s (828 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 7844 files and directories currently installed.)
Preparing to unpack .../util-linux_2.38.1-4ubuntu1.1_arm64.deb ...
Unpacking util-linux (2.38.1-4ubuntu1.1) over (2.38.1-4ubuntu1) ...
Setting up util-linux (2.38.1-4ubuntu1.1) ...
root@9a692adeec83:/# lscpu
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 291
On-line CPU(s) list: 0-290
Vendor ID: ARM
Model name: Neoverse-V2
Model: 0
Thread(s) per core: 1
Core(s) per cluster: 72
Socket(s): -
Cluster(s): 4
Stepping: r0p0
Frequency boost: disabled
CPU(s) scaling MHz: 95%
CPU max MHz: 3384.0000
CPU min MHz: 81.0000
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4
asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3
svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted util-linux (2.38.1-4ubuntu1.1) for lunar have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/252.5-2ubuntu3 (amd64, arm64, ppc64el, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/lunar/update_excuses.html#util-linux

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Andreas Hasenack (ahasenack)]

Hello Joao, or anyone else affected,

Accepted util-linux into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.37.2-4ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted util-linux (2.37.2-4ubuntu3.2) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

cmake-extras/1.6-1 (armhf)
livecd-rootfs/2.765.34 (amd64)
udisks2/2.9.4-1ubuntu2 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#util-linux

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Jamie Nguyen (jamien)]

Verified on 22.04 using util-linux=2.37.2-4ubuntu3.2

$ apt policy util-linux
util-linux:
  Installed: 2.37.2-4ubuntu3.2
  Candidate: 2.37.2-4ubuntu3.2
  Version table:
 *** 2.37.2-4ubuntu3.2 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy-proposed/main arm64 Packages
        100 /var/lib/dpkg/status
     2.37.2-4ubuntu3 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
$ lscpu | head -n10
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 288
On-line CPU(s) list: 0-287
Vendor ID: ARM
Model name: Neoverse-V2
Model: 0
Thread(s) per core: 1
Core(s) per socket: 72

[Mauricio Faria de Oliveira (mfo)]

Jammy verification done in comments 31 (with tag flip) and 39.
Lunar is now Won't Fix (2024-01-17), thus removing lunar tags.

[Mauricio Faria de Oliveira (mfo)]

PS: the Jammy verification done in comment 31 used version 2.37.2-4ubuntu3.1 (staged in this bug), and that in comment 39 used (newer) version 2.37.2-4ubuntu3.2 (also staged, in bug 2048092) -- both have positive results.

BTW, since the newer upload is still planned for staging, not removing the block-proposed-jammy tag, IIUIC.

"""
In principle the block-proposed-<series> tag should be removed by an SRU team member when accepting a newer upload not planned for further staging.
But if they overlook this, it's appropriate for whoever notices it (SRU team, or uploader) to remove the block-proposed-<series> tag with a suitable comment when it no longer applies.
"""
@ https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload