On a pine64 or RaspberryPi 3 for some reason lscpu crashes. It runs fine on a mustang device. util-linux-2.29.1-2.fc26.aarch64 Pine64: # lscpu Segmentation fault Mustang: $ 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 7.12.50.20170226-4.fc26 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 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: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. 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. done. (gdb) run Starting program: /usr/bin/lscpu Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb)
[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 ]---
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 read(3, [4420.280002] Unable to handle kernel paging request at virtual address ffff80003edd0000 <panic>
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.) https://github.com/karelzak/util-linux/commit/fb2627cec4c85 https://github.com/karelzak/util-linux/commit/dbbf839586780 I think lscpu needs an update to not try to read /dev/mem on aarch64.
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 Characteristics: 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 Features: 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 ~]#
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).
LGTM: [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
util-linux-2.30-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d905dbef8
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 https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0d905dbef8
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.