Arm-dev

arm-dev@lists.centos.org

2 participants
685 discussions

kernel-generic vs kernel-rpi2
by Kristján Valur Jónsson 08 Dec '17

08 Dec '17

> > BTW, we never had any image for rpi2/rpi3 that was using the > kernel-generic repo Ok, the values are set in /etc/yum/vars. [root@dc03 vars]# ll total 12 -rw-r--r--. 1 root root 6 Dec 5 2016 infra -rw-r--r--. 1 root root 8 Oct 31 10:00 kvariant -rw-r--r--. 1 root root 2 Sep 1 07:02 releasever Seems that the "kvariant" was last modified end of october, probably by some update or other. I'ver reset it to 'rpi2' and hoping for the best. -- Kv, Kristján Valur Jónsson, RVX

4 10

kernel-generic vs kernel-rpi2
by Kristján Valur Jónsson 04 Dec '17

04 Dec '17

> > Both repositories are following now the 4.9.x LTS branch, but : > - kernel generic is built from vanilla/upstream kernel from kernel.org , > so works on all boards supported "upstream" > - rpi2 kernel is the one built from https://github.com/raspberrypi/linux > (that also rebase from upstream LTS but with their patches added in for > the rpi2/rpi3) Lucky that the RPi seems to run, without the specific patches from the foundation. > BTW, we never had any image for rpi2/rpi3 that was using the > kernel-generic repo Weird. I installed in in mid july when I saw it, and downloaded from here http://mirror.centos.org/altarch/7/isos/armhfp/. Something must have gotten screwed up, the CentOS-armhpf-kernel.repo is dated from sept 1st. I'll just swap the baseurl around, update and hope for the best :) -- Kv, Kristján Valur Jónsson, RVX

1 0

kernel-generic vs kernel-rpi2
by Kristján Valur Jónsson 04 Dec '17

04 Dec '17

Hi there. I have two Rpi3s running Centos7 but one from a few months ago. I just ntocied that the kernel repos are different. the older one has a baseurl ending in kernel-generic, while the new one ends with kernel-rpi2. Which one is correct? I notice that they are not updating to the same kernel versions. -- Kv, Kristján Valur Jónsson, RVX

2 1

Just getting started, Looking for pointers.
by Daniel Baker 27 Nov '17

27 Nov '17

Howdy Y'all, Where would be a few good places to start with the Pine64? My Wife bought it for me with the initial crowd-funding and I am just now getting to playing with it. Any good Centos / Ubuntu images? -- Peace and God Bless, - Dan. ######################## DevOps on a Starship: vim /cookbooks/hyperdrive/attributes/alignments.conf git add . commit -m 'Automation is the new Magick.' git push knife cookbook upload hyperdrive

2 1

[Question] CentOS7.4 for ARM update plan
by Zhou Wang 27 Nov '17

27 Nov '17

Hi, I am afraid in the right place to ask this question. Redhat7.4 for ARM64 already released: https://access.redhat.com/articles/3158541 Before this, CentOS7.4 for ARM64 released: https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 As CentOS7.4 just took one internal version of Redhat7.4 as its release version, we should at least backport patches after above Redhat7.4 internal version to CentOS7.4. My question is that is there a plan to backport these patches to CentOS7.4? Or where can I find such plan/schedule? Thanks a lot for any help, Zhou

4 7

Introducing 2017’s extensions to the Arm Architecture
by Jeffrey Walton 27 Nov '17

27 Nov '17

In case it did not make your radar: https://community.arm.com/processors/b/blog/posts/introducing-2017s-extensi… It looks like ARMv8.4 will also provide hardware support for China's SM3 (hash) and SM4 (block cipher), like they support SHA and AES. Jeff

1 0

fake-hwclock
by Kristján Valur Jónsson 21 Nov '17

21 Nov '17

Hi there. I'm running CentOS7 on an RPi3 without hardware clock. I found no suitable "fake-hwclock" (as avilable for raspbian) on the internet, so I implemented my own systemd unit for that. Check out https://github.com/kristjanvalur/fake-hwclock if you're interested. Cheers! -- Kv, Kristján Valur Jónsson, RVX

1 0

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

← Newer
1
...
20
21
22
23
24
25
26
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev