Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1455238 - lscpu crashes on certain arm64 devices
Summary: lscpu crashes on certain arm64 devices
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2017-05-24 14:18 UTC by Peter Robinson
Modified: 2017-07-11 09:46 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-11 09:46:01 UTC
Type: Bug

Attachments (Terms of Use)

Description Peter Robinson 2017-05-24 14:18:26 UTC
On a pine64 or RaspberryPi 3 for some reason lscpu crashes. It runs fine on a mustang device.



# lscpu
Segmentation fault


$ lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             4
NUMA node(s):          1
Model:                 1
BogoMIPS:              100.00
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
NUMA node0 CPU(s):     0-7
Flags:                 fp asimd evtstrm cpuid

Running it through gdb I don't seem to be able to get a backtrace so I'm not sure the best way to provide more information on this:

# gdb lscpu
GNU gdb (GDB) Fedora
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lscpu...Reading symbols from /usr/lib/debug/usr/bin/lscpu.debug...done.
(gdb) run
Starting program: /usr/bin/lscpu 

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Comment 1 Paul Whalen 2017-05-26 14:38:03 UTC
[root@pine64 ~]# lscpu
[86327.397561] Unable to handle kernel paging request at virtual address ffff80007ae15000
[86327.405815] pgd = ffff800075883000
[86327.409255] [ffff80007ae15000] *pgd=0000000000000000
[86327.414287] Internal error: Oops: 96000007 [#1] SMP
[86327.419189] Modules linked in: xt_CHECKSUM tun ipt_MASQUERADE nf_nat_masquerade_ipv4 rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache xt_addrtype ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack br_netfiltem
[86327.490523]  mmc_core extcon_core udc_core
[86327.494672] CPU: 2 PID: 21822 Comm: lscpu Tainted: G        W       4.12.0-0.rc2.git1.1.fc27.aarch64 #1
[86327.504118] Hardware name: sunxi sunxi/sunxi, BIOS 2017.05-rc2 04/25/2017
[86327.510942] task: ffff80007427a600 task.stack: ffff800054fb8000
[86327.516908] PC is at __arch_copy_to_user+0x90/0x220
[86327.521822] LR is at read_mem+0x188/0x1d0
[86327.525859] pc : [<ffff0000084edf10>] lr : [<ffff00000869cff8>] pstate: 60000145
[86327.533299] sp : ffff800054fbbd50
[86327.536637] x29: ffff800054fbbd50 x28: ffff80007ae15000 
[86327.541990] x27: 00000000bae15000 x26: ffff800054fbbeb8 
[86327.547342] x25: ffff000008dc8000 x24: ffff000008cc83b8 
[86327.552694] x23: 0000000000001000 x22: 0000000000000000 
[86327.558045] x21: 0000aaaae1d49790 x20: 0000000000000020 
[86327.563396] x19: 0000000000000020 x18: 0000ffffdfa62338 
[86327.568749] x17: 000000000409d971 x16: 0000000000000000 
[86327.574100] x15: 0000000000000000 x14: 0000000000000010 
[86327.579452] x13: 0a30303035316561 x12: 6278303d534f4942 
[86327.584803] x11: ffffffffffffffff x10: 0000000000000010 
[86327.590155] x9 : 0000000000000037 x8 : 0000000000000001 
[86327.595506] x7 : 0000000000000000 x6 : 0000aaaae1d49790 
[86327.600860] x5 : 0000aaaae1d497b0 x4 : 0000000000000000 
[86327.606213] x3 : 0000000000000020 x2 : 0000000000000020 
[86327.611566] x1 : ffff80007ae15000 x0 : 0000aaaae1d49790 
[86327.616919] Process lscpu (pid: 21822, stack limit = 0xffff800054fb8000)
[86327.623655] Stack: (0xffff800054fbbd50 to 0xffff800054fbc000)
[86327.629436] bd40:                                   ffff800054fbbdb0 ffff0000082f3160
[86327.637317] bd60: ffff80007495d880 0000000000000020 ffff800054fbbeb8 0000aaaae1d49790
[86327.645197] bd80: ffff800054fbbeb8 0000000000000015 0000000000000124 000000000000003f
[86327.653077] bda0: ffff000008a52000 ffff80007427a600 ffff800054fbbe40 ffff0000082f450c
[86327.660955] bdc0: 0000000000000020 ffff80007495d880 0000000000000000 0000aaaae1d49790
[86327.668834] bde0: ffff800054fbbe10 ffff0000082f442c 0000000000000020 ffff80007495d880
[86327.676713] be00: ffff800054fbbeb8 0000000000000000 ffff800054fbbe40 ffff0000082f44e8
[86327.684593] be20: 0000000000000020 ffff80007495d880 0000aaaae1d49790 0000aaaae1d49790
[86327.692473] be40: ffff800054fbbe80 ffff0000082f5684 ffff80007495d880 ffff80007495d880
[86327.700353] be60: 0000aaaae1d49790 0000000000000020 0000000020000000 ffff000000020000
[86327.708233] be80: 0000000000000000 ffff000008083430 0000000000000000 0000800076f1f000
[86327.716114] bea0: ffffffffffffffff 0000ffff83df66c8 0000000060000000 00000000bae15000
[86327.723993] bec0: 0000000000000003 0000aaaae1d49790 0000000000000020 0000000000000000
[86327.731872] bee0: 0000aaaae1d497b0 0000000000000001 0000000000000000 0000ffff83e4ecc0
[86327.739751] bf00: 000000000000003f 0000000000000037 0000000000000010 ffffffffffffffff
[86327.747630] bf20: 6278303d534f4942 0a30303035316561 0000000000000010 0000000000000000
[86327.755508] bf40: 0000000000000000 0000ffff83df66e0 0000ffffdfa62338 0000000000000020
[86327.763387] bf60: 0000000000000003 0000aaaae1d49790 0000aaaabdf7c000 0000aaaae1d49790
[86327.771266] bf80: 0000000000000000 0000000000000000 000000000ee6b280 0000ffffdfa60cf8
[86327.779145] bfa0: 0000aaaabdf68e98 0000ffffdfa60c90 0000aaaabdf64338 0000ffffdfa60c90
[86327.787025] bfc0: 0000ffff83df66c8 0000000020000000 0000000000000003 000000000000003f
[86327.794904] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[86327.802779] Call trace:
[86327.805250] Exception stack(0xffff800054fbbb80 to 0xffff800054fbbcb0)
[86327.811726] bb80: 0000000000000020 0001000000000000 ffff800054fbbd50 ffff0000084edf10
[86327.819605] bba0: ffff80007427a600 0000000000000000 0000000000000001 0000000000000000
[86327.827485] bbc0: 0000000000000001 0000000000000000 ffff80007427ae70 ffff80007427ae70
[86327.835365] bbe0: ffff80007427a600 0000000000000000 0000000000000001 00000000bae15fff
[86327.843244] bc00: 0000000000000000 ffff00000905c000 ffff800054fbbca0 ffff000008144fc8
[86327.851122] bc20: 0000aaaae1d49790 ffff80007ae15000 0000000000000020 0000000000000020
[86327.859001] bc40: 0000000000000000 0000aaaae1d497b0 0000aaaae1d49790 0000000000000000
[86327.866883] bc60: 0000000000000001 0000000000000037 0000000000000010 ffffffffffffffff
[86327.874762] bc80: 6278303d534f4942 0a30303035316561 0000000000000010 0000000000000000
[86327.882640] bca0: 0000000000000000 000000000409d971
[86327.887558] [<ffff0000084edf10>] __arch_copy_to_user+0x90/0x220
[86327.893519] [<ffff0000082f3160>] __vfs_read+0x48/0x128
[86327.898693] [<ffff0000082f450c>] vfs_read+0x8c/0x148
[86327.903690] [<ffff0000082f5684>] SyS_read+0x54/0xb0
[86327.908604] [<ffff000008083430>] el0_svc_naked+0x24/0x28
[86327.913952] Code: a8c12027 a88120c7 d503201f d503201f (a8c12027) 
[86327.920252] ---[ end trace 24281d67c9a68163 ]---

Comment 2 Jeff Bastian 2017-05-26 17:57:03 UTC
Can you run 'strace lscpu' and see what it was doing just before the kernel panic?

On another system with the same problem, I see:

~]# strace lscpu
openat(AT_FDCWD, "/sys/firmware/efi/systab", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0400, st_size=65536, ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa7f00000
read(3, "ACPI20=0x39950014\nACPI=0x3995000"..., 8192) = 71
close(3)                                = 0
munmap(0xffffa7f00000, 65536)           = 0
openat(AT_FDCWD, "/dev/mem", O_RDONLY)  = 3
lseek(3, 1054670848, SEEK_SET)          = 1054670848
[4420.280002] Unable to handle kernel paging request at virtual address ffff80003edd0000

Comment 3 Jeff Bastian 2017-05-26 18:38:22 UTC
A couple of patches went into lscpu a few years ago which try to scrub through /dev/mem looking for the SMBIOS tables.  This is ok on x86 where SMBIOS lives in lowmem, but they're not in a set location on aarch64.  lscpu should instead be looking at /sys/firmware/dmi/* instead on aarch64.  (dmidecode needed similar updates for aarch64 and SMBIOS3 systems.)

I think lscpu needs an update to not try to read /dev/mem on aarch64.

Comment 4 Peter Robinson 2017-05-27 11:19:02 UTC
Doing a dmidecode gives me the following so it might mean that lscpu is crashing due to the bad dmitables, but dmidecode does use the sysfs 

[root@pine64 ~]# dmidecode
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 221 bytes.
Table at 0xBAE15020.

Wrong DMI structures length: 221 bytes announced, only 159 bytes available.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: U-Boot
        Version: 2017.05
        Release Date: 05/10/2017
        ROM Size: 64 kB
                PCI is supported
                BIOS is upgradeable
                Selectable boot is supported
                I2O boot is supported
                Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: sunxi
        Product Name: sunxi
        Version: Not Specified
        Serial Number: 92c000bad5bce8d4
        UUID: 30633239-3030-6162-6435-626365386434
        Wake-up Type: Reserved
        SKU Number: Not Specified
        Family: Not Specified

Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
        Manufacturer: sunxi
        Product Name: sunxi
        Version: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
                Board is a hosting board
        Location In Chassis: Not Specified
        Chassis Handle: 0x0000
        Type: Motherboard

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
        Manufacturer: <BAD INDEX>
        Type: Desktop
        Lock: Not Present
        Version: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: Unspecified
        Contained Elements: 0

Invalid entry length (2). DMI table is broken! Stop.

[root@pine64 ~]#

Comment 5 Karel Zak 2017-05-29 10:52:04 UTC
The latest upstream version (now v2.30-rc2) reads the information from sysfs rather than from /dev/mem. 

Please, try util-linux-2.30-0.1.fc27 (I'm going to update to final v2.30 tomorrow).

Comment 6 Peter Robinson 2017-05-29 12:12:06 UTC

[root@pine64 ~]# lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Model:               4
BogoMIPS:            48.00
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

Comment 7 Fedora Update System 2017-06-22 10:07:56 UTC
util-linux-2.30-1.fc26 has been submitted as an update to Fedora 26.

Comment 8 Fedora Update System 2017-06-23 06:26:44 UTC
util-linux-2.30-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See for
instructions on how to install test updates.
You can provide feedback for this update here:

Comment 9 Fedora Update System 2017-07-07 22:57:10 UTC
util-linux-2.30-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.