cross-distro October 2014

cross-distro@lists.linaro.org

8 participants
5 discussions

MariaDB crash + memory corruption on AArch64

by Steve Capper

Hi All, This is just a heads-up that we've run into quite a horrible crash + data corruption issue with MariaDB when running sysbench with a large number of threads on a couple of AArch64 platforms. I believe the problem can be attributed to the code used to release the custom mutexes used by the storage engine. I have logged a ticket (and attached an emergency fix) here: https://mariadb.atlassian.net/browse/MDEV-6615 Cheers, -- Steve Capper

9 years, 10 months

[RFC PATCH 0/1] arm64: Fix /proc/cpuinfo

by Mark Rutland

Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a manner which prevents some otherwise portable applications from functioning as expected. Specifically, the "Features" line describes the 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for certain applications which attempt to parse /proc/cpuinfo to detect features rather than directly using the hwcaps exposed via auxval. Additionally, the arm64 /proc/cpuinfo format only provides identifying information for a single CPU (unlike 32-bit), which is problematic for systems with heterogeneous CPUs (i.e. big.LITTLE). This patch attempts to solve both issues. I believe the contentious part is what to do with the Features line, and for that there are a number of possibilities: [a] Only print the 64-bit hwcaps This would match our current behaviour. However certain 32-bit applications will not detect CPU features correctly, and could fail to launch. The appropriate hwcaps are available in auxval, but this will not be of help to existing binaries. [b] Append the 64-bit and 32-bit hwcaps This would allow for a consistent format. However, some human-readable hwcap names have been reused for analogous instruction set features (e.g. "aes") despite 32-bit and 64-bit instruction set support being largely unrelated per the architecture. This could lead to applications mis-detecting instruction set support on some CPUs in future, and may be misleading to a casual reader. [c] Print different hwcaps for compat tasks This would allow for 32-bit and 64-bit applications to function correctly. Having the format differ depending on the instruction set of the application reading /proc/cpuinfo may be misleading in some cases (e.g. a human using a 32-bit cat to read /proc/cpuinfo on a 64-bit system). [d] Print different hwcaps dependent on the personality. This would allow for 32-bit and 64-bit applications to function correctly, but for some 32-bit applications the personality would need to be set explicitly by the user. This patch takes approach d, aligning with what we do for COMPART_UTS_NAME and COMPAT_ELF_PLATFORM function. Below are sample output on a 32-bit platform and a 64-bit platform before and after this patch (with and without LINUX32 personality). Does it sound reasonable for the /proc/cpuinfo format to vary depending on the task or personality? Are there applications for which any of these strategies will not work? Thanks, Mark. [1] arm, v3.17, Versatile Express A15x2 A7x3 coretile ---->8---- processor : 0 model name : ARMv7 Processor rev 1 (v7l) Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc0f CPU revision : 1 processor : 1 model name : ARMv7 Processor rev 1 (v7l) Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc0f CPU revision : 1 processor : 2 model name : ARMv7 Processor rev 1 (v7l) Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 1 processor : 3 model name : ARMv7 Processor rev 1 (v7l) Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 1 processor : 4 model name : ARMv7 Processor rev 1 (v7l) Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 1 Hardware : ARM-Versatile Express Revision : 0000 Serial : 0000000000000000 ----8<---- [2] arm64, v3.17, Juno platform ---->8---- Processor : AArch64 Processor rev 0 (aarch64) processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: AArch64 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 Hardware : Juno ----8<---- [3] arm64, v3.17 + this patch, Juno platform ---->8---- processor : 0 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 1 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 2 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 3 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 4 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd07 CPU revision : 0 processor : 5 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd07 CPU revision : 0 ----8<---- [4] arm64, v3.17 + this patch, Juno platform, LINUX32 personality ---->8---- processor : 0 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 1 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 2 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 3 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 0 processor : 4 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd07 CPU revision : 0 processor : 5 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd07 CPU revision : 0 ----8<---- Mark Rutland (1): arm64: Fix up /proc/cpuinfo arch/arm64/kernel/setup.c | 96 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 72 insertions(+), 24 deletions(-) -- 1.9.1

10 years, 2 months

Re: [RFC PATCH 1/1] arm64: Fix up /proc/cpuinfo

by Robert Wilkinson

> + seq_printf(m, "CPU implementer\t: 0x%02x\n", > + MIDR_IMPLEMENTOR(midr)); Please can I request that MIDR_IMPLEMENTOR is renamed MIDR_IMPLEMENTER. I much prefer consistency - if I see "implementer" on screen I expect a macro called MIDR_IMPLEMENTER to be invoked? Bob

10 years, 3 months

Btrfs on arm64

by Steve Capper

Hi All, This is just a heads-up for anyone wanting to run btrfs with arm64. When creating a new btrfs volume there is an option, sectorsize, which is by default set to the current PAGE_SIZE. If one tries to mount btrfs with a PAGE_SIZE != sectorsize, it will fail to mount and the following will be found in dmesg: BTRFS: Incompatible sector size This should obviously be a cause for concern for those who intend to create a btrfs volume running at one PAGE_SIZE (for instance an installer kernel with 4K), and mounting it with a different PAGE_SIZE (i.e. when running a server kernel with 64K). There is some work being done by Chandan Rajendra at IBM to fix this: http://comments.gmane.org/gmane.comp.file-systems.btrfs/38808 I've not tried it yet, but will do soon. Cheers, -- Steve

10 years, 3 months

libgc / atomic-ops barriers problem: ARMv7 software running on ARMv8

by Steve McIntyre

Hi folks, It's probably worth sharing something I found yesterday, running Debian Wheezy binaries on a couple of different ARMv8 machines... libgc embeds a copy of libatomic-ops, and until very recently, libatomic-ops has been continuing to use (deprecated) CP15 barriers [1] when building for ARMv7 instead of the recommended DMB instruction. On v7 machines that's been working fine, but v8 does not support these old-style barriers at all. I found this trying to run w3m, and it failed immediately with "Illegal instruction". There's ongoing discussion about a kernel patch for arm64 to catch this exception (and others) [2], but it's not gone upstream yet. Other packages that I can see using ligbc on Debian are: asymptote chase debfoster ecl fauhdlc gcc-3.3 goo guile-2.0 inkscape kaya neko parser stalin synopsis w3m There may be quite a few more using older versions of libatomic-ops too - be warned. :-( [1] e.g. mcr 15, 0, r3, cr7, cr10, {5} [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/361430 Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

10 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro October 2014