Arm-dev October 2017

arm-dev@lists.centos.org

11 participants
10 discussions

rng-tools missing and /dev/hwrng without driver
by SW＠EU 31 Oct '25

31 Oct '25

Hi, today I will report a problem that is released to ipa-server. This server contains a certificate authority and such service need many entropy. The default on CentOS 7 on a Banana PI is not enough, i.e. $(cat /proc/sys/kernel/random/entropy_avail) is less than 1000. I have solved this in meantime by installing and enabling of haveged from the EPEL repository. Normally it would be done by installing the rng-tools. But there are two problems: 1. The rng-tools was not in the repositories, so I have downloaded rng-tools-5-8.fc24.armv7hl.rpm because this are the same version which is included in CentOS 7.3 for x86_64. 2. This rng-tools are usable but the daemon starts and stops immediately with the following error message: # rngd -v /dev/hwrng: No such device /dev/tpm0: No such file or directory No entropy sources found, exiting This is not the problem of this binary it is a problem of the Kernel. /dev/hwrng exists and if I remove it then it reappears after reboot, but # ls -l /dev/hwrng crw-------. 1 root root 10, 183 1. Jan 1970 /dev/hwrng # udevadm info -a -n /dev/hwrng Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/virtual/misc/hw_random': KERNEL=="hw_random" SUBSYSTEM=="misc" DRIVER=="" ATTR{rng_current}=="none" ATTR{rng_available}=="" there is no driver for this device. I have searched and found this link http://forum.lemaker.org/thread-23618-1-1.html which includes a link to the full story. If I read all right then on bananian /dev/hwrng appears only if the adapted or a more actual sun4i-ss.ko module is loaded (there is written: "module author has indicated this will be going into the mainline kernel shortly“). This module is also loaded on a Banana PI with current CentOS 7. So does the kernel of CentOS 7.3 for ARM32 include this patch and if yes why it does not work or otherwise why this device appears but has no driver? TIA, Silvio Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 4

EPEL repo not available?
by Boyd Ako 31 Oct '25

31 Oct '25

Can anybody verify that the EPEL repo for ARMHFP isn’t available? I keep getting an error saying the REPOMD file isn’t there when running yum. It works if I use —disablerepo=epel\* when using yum. But, there might be some stuff in the EPEL that I’m looking for. Running it on a Raspberry Pi 3 and trying to get Nagios installed for home use. Domo, Boyd H. Ako boyd.hanalei.ako(a)gmail.com (424) 244-9653 https://www.boydhanaleiako.me “Coming together is a beginning. Keeping together is progress. Working together is success.” -Henry Ford PGP/GPG Public Key: https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134

4 3

Gigabyte MP30-AR0
by Gordan Bobic 31 Oct '25

31 Oct '25

Hi, I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions? Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM? Thanks. Gordan

13 203

ACPI
by Jon Masters 20 Oct '17

20 Oct '17

Hi all, Most of you know me. For those who don't, I'm Chief ARM Architect at Red Hat and started the internal Red Hat ARM team back in 2011. I've also worked on creating most of the ARM server standards, and with every silicon vendor since their design was a paper napkin drawing. So it is with some authority I can tell you that ARM servers without ACPI have no future. Those of you booting with "acpi=off" are running machines completely in violation of the ARM server specs (which mandate the use of ACPI tables). You can choose to do this, but such configs have never been tested and are completely guaranteed to break randomly in the future when you update the distribution, or the hardware. But not everyone has fully gotten this message. Beginning in the next release of the upstream distro from which CentOS inherits its sources, there is a nasty warning message which will be printed if you boot while attempting to disable ACPI, or even if the platform contains DeviceTree tables (whether used or not). The kernel will also taint itself if it detects the presence of DeviceTree on a platform at all. Going forward, I am instituting logic that will cause the kernel to panic and fail to boot at all when a platform contains a DeviceTree (whether used or not) unless some parameter like "platform_is_broken" is passed to the kernel. This is irrespective of whether you actually boot with ACPI or not. All platforms that aren't simply ACPI must be removed from the face of the earth as quickly as possible and replaced with fully standardized ones compliant with the ARM server specs. The good news is that firmware updates will allow anyone still shipping a DeviceTree to remove it from future platform updates to be compliant. Now is a good time to stop thinking about disabling ACPI. It is only going to get much, much harder to turn it off. Jon.

3 4

thunderx support patch
by Lomovtsev, Vadim 18 Oct '17

18 Oct '17

Hi Jim, Could you please apply attached patches on top of 4.11.0-22.el7 and issue CentOS kernel update? I believe when RHEL 7.4 will be released CentOS will switch onto it's kernel we probably will need to rework this list... Following config options expected to be set to 'y': CONFIG_ACPI_APEI_SEA=y CONFIG_HIST_TRIGGERS=y WBR, Vadim ---- Patches agenda is following: Andi Kleen (2): perf xyarray: Save max_x, max_y perf evsel: Fix buffer overflow while freeing events Ard Biesheuvel (2): fs/proc: kcore: use kcore_list type to check for vmalloc/module address arm64: mm: select CONFIG_ARCH_PROC_KCORE_TEXT Bob Moore (1): ACPICA: Add support for new SRAT subtable David Daney (2): PCI: Mark Cavium CN8xxx to avoid bus reset PCI: Avoid bus reset if bridge itself is broken Eric Biggers (3): KEYS: fix dereferencing NULL payload with nonzero length KEYS: fix freeing uninitialized memory in key_update() KEYS: encrypted: avoid encrypting/decrypting stack buffers Ganapatrao Kulkarni (8): ACPICA: iasl: Update to IORT SMMUv3 disassembling ACPI/IORT: numa: Add numa node mapping for smmuv3 devices irqchip/gic-v3-its: Add ACPI NUMA node mapping arm64: perf: Ignore exclude_hv when kernel is running in HYP perf utils: passing pmu as a parameter to function get_cpuid_str perf tools arm64: Add support for get_cpuid_str function. perf utils: Add helper function is_pmu_core to detect PMU CORE devices perf vendor events arm64: Add ThunderX2 implementation defined pmu core events George Cherian (1): i2c: xlp9xx: Enable HWMON class probing for xlp9xx Hu Huajun (1): KVM: ARM64: fix phy counter access failure in guest. Jan Glauber (1): PCI: Avoid slot reset if bridge itself is broken Jan Kara (25): fsnotify: Update comments fsnotify: Move mark list head from object into dedicated structure fsnotify: Remove unnecessary tests when showing fdinfo audit: Abstract hash key handling audit_tree: Use mark flags to check whether mark is alive fsnotify: Move object pointer to fsnotify_mark_connector fsnotify: Make fsnotify_mark_connector hold inode reference fsnotify: Remove indirection from mark list addition fsnotify: Move fsnotify_destroy_marks() fsnotify: Move locking into fsnotify_recalc_mask() fsnotify: Move locking into fsnotify_find_mark() fsnotify: Determine lock in fsnotify_destroy_marks() fsnotify: Remove indirection from fsnotify_detach_mark() fsnotify: Avoid double locking in fsnotify_detach_from_object() fsnotify: Remove useless list deletion and comment fsnotify: Lock object list with connector lock fsnotify: Free fsnotify_mark_connector when there is no mark attached inotify: Remove inode pointers from debug messages inotify: Do not drop mark reference under idr_lock fsnotify: Move queueing of mark for destruction into fsnotify_put_mark() fsnotify: Detach mark from object list when last reference is dropped fsnotify: Remove special handling of mark destruction on group shutdown fsnotify: Provide framework for dropping SRCU lock in ->handle_event fsnotify: Pass fsnotify_iter_info into handle_event handler fanotify: Release SRCU lock when waiting for userspace response Jayachandran C (10): PCI: Add device flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT PCI: Avoid generating invalid ThunderX2 DMA aliases dt-bindings: Add arm64 ARCH_THUNDER2 platform documentation arm64: dts: move from ARCH_VULCAN to ARCH_THUNDER2 MAINTAINERS: Broadcom Vulcan is now Cavium ThunderX2 tty: amba-pl011: Fix spurious TX interrupts ahci: thunderx2: Fix for errata that affects stop engine ahci: thunderx2: stop engine fix update ACPI / APD: Add clock frequency for ThunderX2 I2C controller i2c: xlp9xx: Get clock frequency with clk API Jiri Olsa (1): perf tools: Force uncore events to system wide monitoring Jonathan (Zhixiong) Zhang (1): acpi: apei: panic OS with fatal error status block Kamlakant Patel (1): i2c: xlp9xx: Handle I2C_M_RECV_LEN in msg->flags Loc Ho (1): ACPI: APEI: Enable APEI multiple GHES source to share a single external IRQ Lorenzo Pieralisi (1): ARM64/ACPI: Fix BAD_MADT_GICC_ENTRY() macro implementation Mark Rutland (1): arm64: pmuv3: handle pmuv3+ Mark Salter (1): ACPI / irq: Fix return code of acpi_gsi_to_irq() Nate Watterson (1): iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range Robert Richter (1): irqchip/gic-v3-its: Remove ACPICA version check for ACPI NUMA Robin Murphy (15): iommu/dma: Don't reserve PCI I/O windows iommu/dma: Handle IOMMU API reserved regions iommu/dma: Make PCI window reservation generic iommu/dma: Convert to address-based allocation iommu/dma: Clean up MSI IOVA allocation iommu/dma: Plumb in the per-CPU IOVA caches iommu/io-pgtable-arm-v7s: Check table PTEs more precisely iommu/io-pgtable-arm: Improve split_blk_unmap iommu/io-pgtable-arm-v7s: Refactor split_blk_unmap iommu/io-pgtable: Introduce explicit coherency iommu/io-pgtable-arm: Support lockless operation iommu/io-pgtable-arm-v7s: Support lockless operation iommu/arm-smmu: Remove io-pgtable spinlock iommu/arm-smmu-v3: Remove io-pgtable spinlock iommu/dma: Don't touch invalid iova_domain members Shiju Jose (1): ACPI/APEI: Handle GSIV and GPIO notification types Tyler Baicar (11): acpi: apei: read ack upon ghes record consumption ras: acpi/apei: cper: add support for generic data v3 structure cper: add timestamp print to CPER status printing efi: parse ARM processor error arm64: exception: handle Synchronous External Abort acpi: apei: handle SEA notification type for ARMv8 efi: print unrecognized CPER section ras: acpi / apei: generate trace event for unrecognized CPER section trace, ras: add ARM processor error trace event arm/arm64: KVM: add guest SEA support acpi: apei: check for pending errors when probing GHES entries Vadim Lomovtsev (2): EDAC, thunderx: Fix a warning during l2c debugfs node creation PCI: quirks: update Cavium ThunderX ACS quirk implementation .../devicetree/bindings/arm/cavium-thunder2.txt | 8 + Documentation/devicetree/bindings/arm/cpus.txt | 1 + MAINTAINERS | 9 +- arch/arm/include/asm/kvm_arm.h | 10 + arch/arm/include/asm/system_misc.h | 5 + arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/broadcom/Makefile | 1 - arch/arm64/boot/dts/cavium/Makefile | 1 + .../vulcan-eval.dts => cavium/thunder2-99xx.dts} | 9 +- .../vulcan.dtsi => cavium/thunder2-99xx.dtsi} | 15 +- arch/arm64/include/asm/acpi.h | 6 +- arch/arm64/include/asm/esr.h | 1 + arch/arm64/include/asm/kvm_arm.h | 10 + arch/arm64/include/asm/system_misc.h | 2 + arch/arm64/kernel/perf_event.c | 30 +- arch/arm64/mm/fault.c | 80 ++- drivers/acpi/acpi_apd.c | 6 + drivers/acpi/apei/Kconfig | 15 + drivers/acpi/apei/ghes.c | 260 +++++++-- drivers/acpi/apei/hest.c | 7 +- drivers/acpi/arm64/iort.c | 29 +- drivers/acpi/irq.c | 4 +- drivers/ata/libahci.c | 18 +- drivers/edac/thunderx_edac.c | 2 +- drivers/firmware/efi/cper.c | 204 +++++++- drivers/i2c/busses/i2c-xlp9xx.c | 45 +- drivers/iommu/arm-smmu-v3.c | 38 +- drivers/iommu/arm-smmu.c | 50 +- drivers/iommu/dma-iommu.c | 290 ++++++---- drivers/iommu/io-pgtable-arm-v7s.c | 177 ++++--- drivers/iommu/io-pgtable-arm.c | 185 ++++--- drivers/iommu/io-pgtable.h | 6 + drivers/iommu/iova.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 76 ++- drivers/pci/pci.c | 8 + drivers/pci/quirks.c | 50 +- drivers/pci/search.c | 7 +- drivers/ras/ras.c | 15 + drivers/tty/serial/amba-pl011.c | 23 +- fs/inode.c | 3 - fs/mount.h | 2 +- fs/namespace.c | 3 - fs/notify/dnotify/dnotify.c | 6 +- fs/notify/fanotify/fanotify.c | 20 +- fs/notify/fdinfo.c | 16 +- fs/notify/fsnotify.c | 50 +- fs/notify/fsnotify.h | 48 +- fs/notify/group.c | 11 +- fs/notify/inode_mark.c | 94 +--- fs/notify/inotify/inotify.h | 3 +- fs/notify/inotify/inotify_fsnotify.c | 7 +- fs/notify/inotify/inotify_user.c | 54 +- fs/notify/mark.c | 582 +++++++++++++++------ fs/notify/vfsmount_mark.c | 62 +-- fs/proc/kcore.c | 2 +- include/acpi/actbl1.h | 12 +- include/acpi/actbl2.h | 4 + include/acpi/ghes.h | 48 +- include/linux/cper.h | 54 ++ include/linux/dma-iommu.h | 5 + include/linux/fs.h | 4 +- include/linux/fsnotify_backend.h | 51 +- include/linux/pci.h | 2 + include/linux/ras.h | 17 + include/ras/ras_event.h | 90 ++++ include/uapi/linux/uuid.h | 6 +- kernel/audit_fsnotify.c | 3 +- kernel/audit_tree.c | 66 ++- kernel/audit_watch.c | 3 +- kernel/auditsc.c | 5 +- security/keys/encrypted-keys/encrypted.c | 17 +- security/keys/key.c | 5 +- security/keys/keyctl.c | 4 +- tools/perf/arch/arm64/util/Build | 1 + tools/perf/arch/arm64/util/header.c | 60 +++ tools/perf/arch/powerpc/util/header.c | 2 +- tools/perf/arch/x86/util/header.c | 2 +- tools/perf/builtin-stat.c | 33 +- tools/perf/pmu-events/arch/arm64/mapfile.csv | 15 + .../arm64/thunderx2/implementation-defined.json | 62 +++ tools/perf/tests/openat-syscall-all-cpus.c | 2 +- tools/perf/tests/openat-syscall.c | 2 +- tools/perf/util/evlist.c | 12 +- tools/perf/util/evsel.c | 37 +- tools/perf/util/evsel.h | 7 +- tools/perf/util/header.h | 3 +- tools/perf/util/parse-events.c | 5 +- tools/perf/util/pmu.c | 48 +- tools/perf/util/xyarray.c | 2 + tools/perf/util/xyarray.h | 12 + virt/kvm/arm/arm.c | 4 +- virt/kvm/arm/mmu.c | 36 +- 92 files changed, 2443 insertions(+), 971 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder2.txt rename arch/arm64/boot/dts/{broadcom/vulcan-eval.dts => cavium/thunder2-99xx.dts} (72%) rename arch/arm64/boot/dts/{broadcom/vulcan.dtsi => cavium/thunder2-99xx.dtsi} (88%) create mode 100644 tools/perf/arch/arm64/util/header.c create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv create mode 100644 tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json -- 2.13.6

2 1

ThunderX boot-time linkup issue
by Itaru Kitayama 16 Oct '17

16 Oct '17

Hi, Our 2-socket ThunderX server (GIGABYTE model R150-T62) fails to link up one of the 4 fibre ports, part of the SoC at boot time for some reason. Bringing up the port manually fails too: # ifup enP2p1s0f1 # ifdown enP2p1s0f1 [30836.757508] IPv6: ADDRCONF(NETDEV_UP): enP2p1s0f1: link is not ready Device 'enP2p1s0f1' successfully disconnected. # ifup enP2p1s0f1 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5) The above is misleading as the port is not activated unless we re-plug the fibre cable. Has anyone hit this issue or should we suspect the HW issue? Itaru PS We've tested all the other three physical ports; none worked.

1 0

kernel 4.11.0-22.el7.2.aarch64 does not boot on ThunderX
by Itaru Kitayama 13 Oct '17

13 Oct '17

Hi, In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX. Here's the HW details: http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.) I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW. The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel. Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon? Itaru

6 9

Version of GCC used to compile?
by Richard Henwood 12 Oct '17

12 Oct '17

Hi All, Can you advise how I can discover which version of GCC was used to compile the CentOS bits that I'm using? best regards,Richard

2 1

Centos support for Marvell Armada 7k/8k
by Marcin Wojtas 05 Oct '17

05 Oct '17

Hi, As for the news, unmodified CentOS-7-aarch64 downloaded from http://mirror.centos.org/altarch/7/isos/aarch64/ works great on Marvell Armada 8040 MacchiatoBin (http://macchiatobin.net/) You can see vmlinuz-4.11.0-22.el7a.aarch64 bootlog here: https://pastebin.com/kuDQRzDV All interfaces that are supported in the mainline linux kernel (with ACPI) work fine with Centos image as well. However as there's an effort to add ACPI support to remaining interfaces (e.g. network or sd/mmc controllers), we would like backport upstream patches to your tree. Hence I have a couple of questions in addition to what can be found in https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64/Contributions: 1. Are the Centos kernel sources accessible in some kind of public repository? 2. When sending patches to arm-dev, do you require original commit log and URL to adequate patch in the kernel.org? 3. Is patch existence in linux-next sufficient for you to accept it? 4. I imagine proceeding in two steps - align drivers between v4.11 and mainline first and later add (still being developed) ACPI support patches once they are ready and merged upstream. Would it be ok for you? 5. Do you have some kind of merge windows/release cycles to follow, when upstreaming patches? Given current quality of Centos support for new family of ARM64 SoCs, how about mentioning Armada 7k/8k family in 'Supported Hardware' section on https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 ? Best regards, Marcin

2 4

CentOS 7.4 Gnome-shell crashes
by Phong Vo 04 Oct '17

04 Oct '17

Hi Jim, Currrently, gnome-shell core dumps on latest aarch64 build. The issue appears to be the same as reported here https://bugzilla.redhat.com/show_bug.cgi?id=1429050 RHELSA 7.4 does not have the issue and it looks like RHEL has a more up-to-date version of llvmpipe mesa-private-llvm-3.9.1-3.p1.el7a.aarch64.rpm while CentOS version is mesa-private-llvm-3.9.1-3.el7.aarch64.rpm Please see if you can release an RPM update for this. Thanks, -Phong

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev October 2017