Ubuntu
util-linux package

[LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies

Bug #1732865 reported by bugproxy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
The Ubuntu-power-systems project
Fix Released
High
Canonical Foundations Team
util-linux (Ubuntu)
Fix Released
High
Canonical Foundations Team
Xenial
Fix Released
Undecided
Unassigned
Artful
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
lscpu fails to list CPU max and min frequencies if some CPUs are guarded.

[Regression potential]
Isolated change to lscpu min/max CPU frequency output, so the worst that could happen is that it fails to work elsewhere.

[Test case]
1. Clone https://github.com/open-power/op-test-framework
2. Run this command to GUARD the cpu.
./op-test --bmc-type FSP --bmc-ip $FSPIP --bmc-username dev --bmc-password FipSdev --host-ip $HOSTIP --host-user root --host-password passw0rd --ffdcdir test-reports/ --run testcases.OpTestHMIHandling.MalfunctionAlert
3. Repeat again, so that multiple CPUs are guarded.
4. Run lscpu
5. Observe that no CPU frequencies are displayed:
CPU max MHz: (null)
CPU min MHz: (null)
6. Install util-linux from -proposed.
7. Run lscpu again
8. Observe that max and min CPU frequencies are correctly displayed.

== Comment: #0 - Pridhiviraj Paidipeddi <email address hidden> - 2017-01-03 05:34:32 ==
---Problem Description---
After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies

Contact Information = <email address hidden>

---uname output---
Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = PowerNV 8284-22A

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

---Steps to Reproduce---
 1. Read lscpu output
2. Inject HMI Non recoverable error three times
3. Read lscpu output again
compare the output cpu frequencies will list as NULL

Stack trace output:
 no

Oops output:
 no

Userspace tool common name: lscpu

Userspace rpm: util-linux

The userspace tool has the following bit modes: 64-bit

System Dump Info:
  The system is not configured to capture a system dump.

Userspace tool obtained from project website: na

*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach sysctl -a output output to the bug.
-Attach ltrace and strace of userspace application.

Before CPU's are garded:
root@p8wookie:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 112
On-line CPU(s) list: 0-71,80-103,112-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 4322.0000
CPU min MHz: 2061.0000
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 0-31
NUMA node1 CPU(s): 32-63
NUMA node16 CPU(s): 64-71,80-95
NUMA node17 CPU(s): 96-103,112-127

After 4 cores are garded:
root@p8wookie:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 96
On-line CPU(s) list: 8-55,64-71,80-103,112-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 32-55
NUMA node16 CPU(s): 64-71,80-95
NUMA node17 CPU(s): 96-103,112-127

== Comment: #1 - Pridhiviraj Paidipeddi <email address hidden> - 2017-01-11 07:06:59 ==
root@p8wookie:~# dmesg |grep -i powernv
[ 0.000000] Using PowerNV machine description
[ 0.331564] EEH: PowerNV platform initialized
[ 0.907250] powernv-rng: Registering arch random hook.
[ 1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0
[ 1.507167] powernv_idle_driver registered
[ 34.184048] powernv_rng: Registered powernv hwrng.
[ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree
[ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x000000, prod_id: 0x0000, dev_id: 0x00)
root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ
[ 42.297825315,7] OCC Common Area at 0x3b00000 size 1MB
[ 42.297854780,7] OCC Common Area at 0x2000800000 size 1MB
[ 42.297884305,7] OCC Common Area at 0x2000800000 size 1MB
[ 42.297914258,7] OCC Common Area at 0x2000800000 size 1MB
[ 42.310897465,7] HBRT: OCC common base 0000002000800000 : 00800000
[ 42.317109440,7] HBRT: OCC common base 0000002000800000 : 00800000
[ 42.323969570,7] HBRT: OCC common base 0000002000800000 : 00800000
[ 42.330941943,7] HBRT: OCC common base 0000002000800000 : 00800000
[ 5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29
[ 6.017413373,7] HBRT: OCC Load requested
[ 6.017414365,7] HBRT: Calling loadOCC() homer 0000002001400000, occ_common_area 0000002000800000, chip 0000
[ 6.017553013,7] HBRT: Calling loadOCC() homer 000000003a000000, occ_common_area 0000002000800000, chip 0001
[ 6.017666150,7] HBRT: Calling loadOCC() homer 0000002800400000, occ_common_area 0000002000800000, chip 0010
[ 6.017790110,7] HBRT: Calling loadOCC() homer 0000001000400000, occ_common_area 0000002000800000, chip 0011
[ 6.017929155,6] HBRT: OCC Start requested
[ 6.042511828,7] HBRT: startOCCs() rc = 0
[ 22.190466757,5] irq 11 name: psi:occ (7/8)
[ 22.190474587,5] irq 20011 name: psi:occ (7/56)
[ 22.193374475,7] OCC: Chip 00 Data (00000020015f8000) = 010100bcfb000000
[ 22.193376434,7] OCC: Chip 01 Data (000000003a1f8000) = 010100bcfb000000
[ 22.193378259,7] OCC: Chip 10 Data (00000028005f8000) = 010100bcfb000000
[ 22.193380201,7] OCC: Chip 11 Data (00000010005f8000) = 010100bcfb000000
[ 22.193382038,5] OCC: All Chip Rdy after 0 ms
[ 22.193415815,7] OCC: CPU pstate state device tree init
[ 22.193417077,7] OCC: Data ( 20015f8000) = 10100bcfb000000 0
[ 22.193418948,7] OCC: Min -68 Nom -5 Max 0 Nr States 69
[ 22.193941077,7] OCC: Chip 0 Core c PPMSR c2c2bc0008000000
[ 22.194457253,7] OCC: Chip 0 Core d PPMSR c8c8bc0008000000
[ 22.194973388,7] OCC: Chip 0 Core e PPMSR cecebc0008000000
[ 22.195536559,7] OCC: Chip 1 Core 6 PPMSR d3d3bc0008000000
[ 22.196053033,7] OCC: Chip 1 Core c PPMSR d9d9bc0008000000
[ 22.196568836,7] OCC: Chip 1 Core e PPMSR dfdfbc0008000000
[ 22.197152602,7] OCC: Chip 10 Core 5 PPMSR c2c2bc0008000000
[ 22.197668468,7] OCC: Chip 10 Core 6 PPMSR c8c8bc0008000000
[ 22.198184937,7] OCC: Chip 10 Core e PPMSR cecebc0008000000
[ 22.198730221,7] OCC: Chip 11 Core 4 PPMSR d3d3bc0008000000
[ 22.199245360,7] OCC: Chip 11 Core 5 PPMSR d9d9bc0008000000
[ 22.199760182,7] OCC: Chip 11 Core 6 PPMSR dedebc0008000000
root@p8wookie:~#

root@p8wookie:~#
root@p8wookie:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 96
On-line CPU(s) list: 8-31,40-63,72-119
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 40-63
NUMA node16 CPU(s): 72-95
NUMA node17 CPU(s): 96-119

== Comment: #3 - MAMATHA INAMDAR <email address hidden> - 2017-01-24 00:23:03 ==
Not able to recreate this issue, I am facing some other issue while injecting HMI Non recoverable error

Pridhivi,
Can you please provide steps to reproduce with the commands

== Comment: #4 - Pridhiviraj Paidipeddi <email address hidden> - 2017-02-10 02:04:56 ==
Hi Mamatha
I am able to reproduce with below steps.

On Host:
#lscpu
#service kdump-tools stop
#echo 10 > /proc/sys/kernel/panic

On FSP:
$ getscom pu.ex 10013100 -all
$ putscom pu.ex 10013100 1000000000000000 -n0 -p00 -c6

Repeat the above process 4 times with each time on a different chip with master core getting injected.

Then run

lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 88
On-line CPU(s) list: 16-39,48-71,80-95,104-127
Thread(s) per core: 8
Core(s) per socket: 2
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 16-31
NUMA node1 CPU(s): 32-39,48-63
NUMA node16 CPU(s): 64-71,80-95
NUMA node17 CPU(s): 104-127

== Comment: #5 - MAMATHA INAMDAR <email address hidden> - 2017-02-21 04:40:51 ==
I am able to recreate this issue,
I have a fix for this and will send patch soon to verify this issue.

== Comment: #6 - MAMATHA INAMDAR <email address hidden> - 2017-02-22 01:03:29 ==
Hi Pridhivi,

I have fixed the issue and copied "lscpu" on the p8wookie system,
Can you please verify and update the bug, so that I will submit patch for review

Thanks
Mamatha

== Comment: #7 - Pridhiviraj Paidipeddi <email address hidden> - 2017-02-22 01:14:45 ==
Hi mamatha
Tested on the system which is already having 2 cores garded.
root@p8wookie:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 112
On-line CPU(s) list: 8-31,40-127
Thread(s) per core: 8
Core(s) per socket: 3
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 4322.0000----------------------------------->Works
CPU min MHz: 2061.0000------------------------------------>Works
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-31
NUMA node1 CPU(s): 40-63
NUMA node16 CPU(s): 64-95
NUMA node17 CPU(s): 96-127

And also made all the cores offline except one core and verified it's working fine
root@p8wookie:~# ppc64_cpu --cores-on=1
root@p8wookie:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 112
On-line CPU(s) list: 8-15
Off-line CPU(s) list: 16-31,40-127
Thread(s) per core: 8
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 4322.0000---------------------------------------->Works
CPU min MHz: 2061.0000----------------------------------------->Works
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-15
NUMA node1 CPU(s):
NUMA node16 CPU(s):
NUMA node17 CPU(s):
root@p8wookie:~#

== Comment: #11 - MAMATHA INAMDAR <email address hidden> - 2017-11-17 02:02:41 ==
following is the upstream commit id

commit fc07d9f5aba7c58d9793a6c781d569316dfd25f6
Author: Mamatha Inamdar <email address hidden>
Date: Thu Apr 27 15:52:59 2017 +0530

    lscpu: Read available CPUs max and min frequencies

    Problem:"lscpu frequency-info" command was always reading CPU0
    max and min frequencies. If CPU0 is guarded or offline then it used to
    display max and min frequencies as NULL.

    This patch will read overall CPU max and min frequencies.

See original description
Revision history for this message
bugproxy (bugproxy) wrote : lscpu patch

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-150159 severity-high targetmilestone-inin16042
Changed in ubuntu:
assignee: nobody → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
affects: ubuntu → util-linux (Ubuntu)
Andrew Cloke (andrew-cloke)
Changed in ubuntu-power-systems:
importance: Undecided → High
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
tags: added: triage-g
Revision history for this message
Andrew Cloke (andrew-cloke) wrote :

Apologies, initially misdirected to kernel team. We believe util-linux is owned by server team. Please advise if that is not correct.

Changed in ubuntu-power-systems:
assignee: Canonical Kernel Team (canonical-kernel-team) → David Britton (davidpbritton)
Manoj Iyer (manjo)
Changed in ubuntu-power-systems:
assignee: David Britton (davidpbritton) → Canonical Server Team (canonical-server)
Changed in util-linux (Ubuntu):
assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → David Britton (davidpbritton)
Manoj Iyer (manjo)
Changed in util-linux (Ubuntu):
importance: Undecided → High
Andrew Cloke (andrew-cloke)
Changed in ubuntu-power-systems:
status: New → Triaged
David Britton (dpb)
Changed in util-linux (Ubuntu):
assignee: David Britton (davidpbritton) → Patricia Gaughen (gaughen)
Changed in ubuntu-power-systems:
assignee: Canonical Server Team (canonical-server) → nobody
Andrew Cloke (andrew-cloke)
Changed in ubuntu-power-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Revision history for this message
Steve Langasek (vorlon) wrote :

As I understand it, this change is wanted as an SRU into 16.04. This will need a test case and a description of regression potential. Knowing nothing about how to guard CPUs, how would we go about reproducing the problem?

Changed in util-linux (Ubuntu Xenial):
status: New → Incomplete
Changed in util-linux (Ubuntu):
status: New → Incomplete
Frank Heimes (fheimes)
Changed in ubuntu-power-systems:
status: Triaged → Incomplete
Patricia Gaughen (gaughen)
Changed in util-linux (Ubuntu):
assignee: Patricia Gaughen (gaughen) → Canonical Foundations Team (canonical-foundations)
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2018-01-24 02:09 EDT-------
Testcase:
On Host:
#lscpu
#service kdump-tools stop
#echo 10 > /proc/sys/kernel/panic

On FSP:
$ getscom pu.ex 10013100 -all
$ putscom pu.ex 10013100 1000000000000000 -n0 -p00 -c6
Here -p00--> Is the chip id, -c6 ---> is the core id under that chip, these should be selecte from the output
of the first command "getscom pu.ex 10013100 -all"

Repeat the above process 4 times with each time on a different chip with master core getting injected.

Then run

lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 88
On-line CPU(s) list: 16-39,48-71,80-95,104-127
Thread(s) per core: 8
Core(s) per socket: 2
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: (null)
CPU min MHz: (null)
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 16-31
NUMA node1 CPU(s): 32-39,48-63
NUMA node16 CPU(s): 64-71,80-95
NUMA node17 CPU(s): 104-127

And also there is a automated testcase for this in https://github.com/open-power/op-test-framework
1. Clone the above repo.
2. Runt this command to GUARD the cpu.
./op-test --bmc-type FSP --bmc-ip $FSPIP --bmc-username dev --bmc-password FipSdev --host-ip $HOSTIP --host-user root --host-password passw0rd --ffdcdir test-reports/ --run testcases.OpTestHMIHandling.MalfunctionAlert

Run it multiple times to make multiple CPU's are garded.

This patch makes the customers to easily identify the CPU minimum and maximum frequencies at which it can run(This happens only when there are multiple CPU's are Garded.

Steve Langasek (vorlon)
Changed in util-linux (Ubuntu Xenial):
status: Incomplete → Triaged
Changed in util-linux (Ubuntu):
status: Incomplete → Triaged
Frank Heimes (fheimes)
Changed in ubuntu-power-systems:
status: Incomplete → Triaged
Steve Langasek (vorlon)
description: updated
Revision history for this message
Julian Andres Klode (juliank) wrote :

Am I right that this patch was merged in 2.30-rc1, and all that's left to do therefore is a backport to xenial's 2.27.1?

Revision history for this message
Julian Andres Klode (juliank) wrote :

OK, I checked it myself now, bionic + artful are OK, so all we need is the backport to xenial.

Changed in util-linux (Ubuntu Artful):
status: New → Fix Released
Changed in util-linux (Ubuntu):
status: Triaged → Fix Released
Julian Andres Klode (juliank)
Changed in util-linux (Ubuntu Xenial):
status: Triaged → In Progress
Revision history for this message
Julian Andres Klode (juliank) wrote :

I backported the patches from the upstream git rather than using the patch in here in order to stay closer to upstream. It seems it's not possible to test this in a QEMU VM and it sounds scary to try it on a real productive machine, so I'll probably just go ahead and upload it later, and then it hopefully can be verified in proposed by someone on a real machine.

Revision history for this message
Julian Andres Klode (juliank) wrote :

I uploaded the fix to proposed now. I was _not_ able to verify it, as that requires some telnet stuff on FSPs or something and I don't seem to be getting that. So someone who can actually reproduce the failure needs to check that it's fixed once it is approved for proposed.

Julian Andres Klode (juliank)
description: updated
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted util-linux into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.27.1-6ubuntu3.5 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 and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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!

Changed in util-linux (Ubuntu Xenial):
status: In Progress → Fix Committed
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2018-02-15 07:47 EDT-------
Pridhivi,
Please verify and update your comments

Francis Ginther (fginther)
tags: added: id-5a2eb607f4872474ec5e0a80
Manoj Iyer (manjo)
Changed in ubuntu-power-systems:
status: Triaged → Fix Committed
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-03-06 09:23 EDT-------
I got access to P8 FSP system today, I have verified that lscpu segfaults after first CPU garded.

root@xxxx:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 72
On-line CPU(s) list: 8-79
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
Segmentation fault
root@xxxxx:~#

dmesg logs below errors:
[ 57.463443] lscpu[2057]: unhandled signal 11 at 0000000000000000 nip 00007128aba29b60 lr 00007128aba29b38 code 30001
[ 61.664064] lscpu[2058]: unhandled signal 11 at 0000000000000000 nip 000078c241109b60 lr 000078c241109b38 code 30001
root@xxxxx:~#

Revision history for this message
Steve Langasek (vorlon) wrote :

<email address hidden> what version of the package did you test? We were looking for a verification that the new package does NOT segfault. It's unclear from your comment if you've tested the new version of the package and it failed verification, or if you were testing the previous, known-broken package.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-03-06 10:49 EDT-------
(In reply to comment #28)
> <email address hidden> what version of the package did you test? We were
> looking for a verification that the new package does NOT segfault. It's
> unclear from your comment if you've tested the new version of the package
> and it failed verification, or if you were testing the previous,
> known-broken package.

I have tested with latest proposed package 2.27.1-6ubuntu3.5 and it segfaults after CPU GUARD test, before test lscpu works fine.

root@ltc-test-ci1:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 72
On-line CPU(s) list: 8-79
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
Segmentation fault
root@ltc-test-ci1:~# which lscpu
/usr/bin/lscpu
root@ltc-test-ci1:~# dpkg -S /usr/bin/lscpu
util-linux: /usr/bin/lscpu
root@ltc-test-ci1:~# dpkg -l | grep -i util-linux
ii util-linux 2.27.1-6ubuntu3.5 ppc64el miscellaneous system utilities
root@ltc-test-ci1:~#

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-03-08 01:15 EDT-------
Segmentation fault is may be due to library issue?

Pridhivi,
Can you verify once with upstream build and confirm

(gdb) run(gdb) run
Starting program: /usr/bin/lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 72
On-line CPU(s) list: 8-79
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported

Program received signal SIGSEGV, Segmentation fault.
__GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out>, loc=0x7ffff7f115f0 <_nl_global_locale>) at strtod_l.c:583
583 strtod_l.c: No such file or directory.
(gdb) bt
#0 __GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out>, loc=0x7ffff7f115f0 <_nl_global_locale>) at strtod_l.c:583
#1 0x00007ffff7d9607c in __GI_strtod (nptr=<optimized out>, endptr=<optimized out>) at strtod.c:64
#2 0x00000000100060c0 in ?? ()
#3 0x00000000100030e8 in ?? ()
#4 0x00007ffff7d7309c in generic_start_main (main=0x10001f10, argc=<optimized out>, argv=0x7ffffffffb18, auxvec=0x7ffffffffbd0, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>,
fini=<optimized out>) at ../csu/libc-start.c:291
#5 0x00007ffff7d73298 in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>,
stack_on_entry=<optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:116
#6 0x0000000000000000 in ?? ()
(gdb)

Starting program: /usr/bin/lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 72
On-line CPU(s) list: 8-79
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported

Program received signal SIGSEGV, Segmentation fault.
__GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out>, loc=0x7ffff7f115f0 <_nl_global_locale>) at strtod_l.c:583
583 strtod_l.c: No such file or directory.
(gdb) bt
#0 __GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out>, loc=0x7ffff7f115f0 <_nl_global_locale>) at strtod_l.c:583
#1 0x00007ffff7d9607c in __GI_strtod (nptr=<optimized out>, endptr=<optimized out>) at strtod.c:64
#2 0x00000000100060c0 in ?? ()
#3 0x00000000100030e8 in ?? ()
#4 0x00007ffff7d7309c in generic_start_main (main=0x10001f10, argc=<optimized out>, argv=0x7ffffffffb18, auxvec=0x7ffffffffbd0, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>,
fini=<optimized out>) at ../csu/libc-start.c:291
#5 0x00007ffff7d73298 in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>,
stack_on_entry=<optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:116
#6 0x0000000000000000 in ?? ()
(gdb)

Steve Langasek (vorlon)
tags: added: verification-failed-xenial
Manoj Iyer (manjo)
tags: added: triage-a
removed: triage-g
Revision history for this message
Julian Andres Klode (juliank) wrote :

Can you check whether it works in bionic?

Revision history for this message
Julian Andres Klode (juliank) wrote :

Upstream now contains more fixes:

https://github.com/karelzak/util-linux/commit/0145d84a381fc2fcd7d37e0dbf3d9dff69609ecd
https://github.com/karelzak/util-linux/commit/95f09bc63c564c50ec2c393352801cc056faaea2

So artful, bionic, cosmic should be broken as well, at least if CPU#0 is offline.

Revision history for this message
Robie Basak (racb) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted util-linux into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.27.1-6ubuntu3.6 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 and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

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

Revision history for this message
Julian Andres Klode (juliank) wrote :

<email address hidden> Can you check with the new util-linux in proposed (2.27.1-6ubuntu3.6)? This should fix the crash.

Julian Andres Klode (juliank)
tags: added: verification-needed-xenial
removed: verification-failed-xenial
Frank Heimes (fheimes)
tags: added: triage-g
removed: triage-a
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Could we get a verification of this package?

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2018-07-25 02:53 EDT-------
(In reply to comment #38)
>
> Could we get a verification of this package?

Sorry for the delay in response, machine was not available. Now i got P8 machine where i tested the above proposed package. lscpu works fine even after guarding multiple CPU's from multiple chips. No segfault/crashes.

root@powerkvm2-lp1:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 144
On-line CPU(s) list: 8-15,24-47,56-79,88-95,104-143,152-191
Thread(s) per core: 8
Core(s) per socket: 4
Socket(s): 4
NUMA node(s): 4
Model: 2.1 (pvr 004b 0201)
Model name: POWER8E (raw), altivec supported
CPU max MHz: 3325.0000
CPU min MHz: 2061.0000
Hypervisor vendor: horizontal
Virtualization type: full
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 8-15,24-47
NUMA node1 CPU(s): 56-79,88-95
NUMA node16 CPU(s): 104-143
NUMA node17 CPU(s): 152-191
root@powerkvm2-lp1:~#
root@powerkvm2-lp1:~# dpkg -l | grep -i util-linux
ii util-linux 2.27.1-6ubuntu3.6 ppc64el miscellaneous system utilities
root@powerkvm2-lp1:~#

tags: added: verification-done-xenial
removed: verification-needed-xenial
Revision history for this message
Robie Basak (racb) wrote :

Could someone please also check that lscpu still works without error on amd64? Seems to me that we're fixing an edge case, which is fine, but we should also verify the common case functionality. I'd hate to release something that breaks the world on amd64 just because nobody checked it.

Revision history for this message
Robie Basak (racb) wrote :

(please also state the package version strings tested)

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-07-26 02:01 EDT-------
(In reply to comment #40)
> Could someone please also check that lscpu still works without error on
> amd64? Seems to me that we're fixing an edge case, which is fine, but we
> should also verify the common case functionality. I'd hate to release
> something that breaks the world on amd64 just because nobody checked it.
>
> (please also state the package version strings tested)

Currently we don't have amd64 machines here. Is it possible to test it from distro side?

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

I have verified that lscpu still works on amd64.

Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for util-linux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package util-linux - 2.27.1-6ubuntu3.6

---------------
util-linux (2.27.1-6ubuntu3.6) xenial; urgency=medium

  * d/patches/lscpu-make-min-max-freq-arrays-usage-more-robust.patch,
    d/patches/Avoid-crash-in-min-max-caculation-when-cpu-0-being-o.patch:
    Cherry pick upstream patches to avoid SEGV in min/max frequency.
    LP: #1771345

util-linux (2.27.1-6ubuntu3.5) xenial; urgency=medium

  * d/patches/lscpu-Read-available-CPUs-max-and-min-frequencies.patch,
    d/patches/lscpu-make-cpu_-max-min-_mhz-usage-more-elegant.patch:
    Backport upstream fixes to correctly read minimum and maximum
    CPU frequencies on ppc64 when some cpus are guarded or offline.
    LP: #1732865

 -- Julian Andres Klode <email address hidden> Wed, 16 May 2018 12:36:24 +0200

Changed in util-linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
Andrew Cloke (andrew-cloke)
Changed in ubuntu-power-systems:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.