Re: [PATCH v4 15/15] Documentation for ARC port
On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > On 3/27/20 3:49 PM, Joseph Myers wrote: > > On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote: > > > >> +* Support for ARC HS cores running Linux has been contributed by Synopsys. > >> + > >> + Port requires atleast > >> +- binutils-2.32 (binutils-2_31-branch: commit 6ce881c15fc4, > >> 2018-10-04) > >> +- gcc 8.3 (gcc-8-stable: commit 0d5ba57508c5, 2019-01-29) > >> +- Linux kernel 5.1+ > >> + > >> + ISA: ARCv2 > >> + ABI: 32-bit, soft-float, LE: /lib/ld-linux-arc.so.2 (compatible with > >> + hard-float builds) > > I don't think the default of the dynamic linker name etc. (which should go > > on https://sourceware.org/glibc/wiki/ABIList) belong in the NEWS entry. > > OK, at the time port is ready and about to be committed or now ? I think the wiki should be updated at the time the port is committed. https://sourceware.org/glibc/wiki/NewPorts lists all the wiki pages that should be updated (MAINTAINERS, ABIList, PortStatus, Release/X.Y and the copy for the next release). -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 15/15] Documentation for ARC port
On 3/27/20 3:49 PM, Joseph Myers wrote: > On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote: > >> +* Support for ARC HS cores running Linux has been contributed by Synopsys. >> + >> + Port requires atleast >> +- binutils-2.32 (binutils-2_31-branch: commit 6ce881c15fc4, 2018-10-04) >> +- gcc 8.3 (gcc-8-stable: commit 0d5ba57508c5, 2019-01-29) >> +- Linux kernel 5.1+ >> + >> + ISA: ARCv2 >> + ABI: 32-bit, soft-float, LE: /lib/ld-linux-arc.so.2 (compatible with >> + hard-float builds) > I don't think the default of the dynamic linker name etc. (which should go > on https://sourceware.org/glibc/wiki/ABIList) belong in the NEWS entry. OK, at the time port is ready and about to be committed or now ? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 02/15] ARC: ABI Implementation
On 3/27/20 4:35 PM, Joseph Myers wrote: > On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > >> I added bits in sysdeps/arc/configure.ac and corresponding conditional in >> shlib-version. But I have to ask (embarrassingly). how to I regenerate >> sysdeps/arc/configure. I tried all possibe autoconf cmds with toggles (both >> at >> top and in sysdeps/arc) and even reran configure in build tree with >> --enable-maintainer-mode > autoconf sysdeps/arc/configure.ac > sysdeps/arc/configure Much thanks. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 02/15] ARC: ABI Implementation
On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > I added bits in sysdeps/arc/configure.ac and corresponding conditional in > shlib-version. But I have to ask (embarrassingly). how to I regenerate > sysdeps/arc/configure. I tried all possibe autoconf cmds with toggles (both > at > top and in sysdeps/arc) and even reran configure in build tree with > --enable-maintainer-mode autoconf sysdeps/arc/configure.ac > sysdeps/arc/configure -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 02/15] ARC: ABI Implementation
On 3/26/20 11:48 AM, Joseph Myers wrote: > On Wed, 25 Mar 2020, Vineet Gupta via Libc-alpha wrote: > >> Hardware-wise, ARC can be configured to be LE or BE and software supports >> that >> (cfr Linux or uClibc). The initial glibc port was only aiming LE but we >> ended up >> with BE as well due to a customer engagement. And given much of ARC port is >> currently generic (minimal asm), no real change was needed except enabling >> it in >> this header. We do plan to officially support it so I guess we need some more >> changes in Documentation / ABI listing etc. > > Yes, if you want to support BE then it should be documented as supported, > it should have its own dynamic linker name (with consequent GCC change > required to use that name) and it should have its own build in > build-many-glibcs.py. I added bits in sysdeps/arc/configure.ac and corresponding conditional in shlib-version. But I have to ask (embarrassingly). how to I regenerate sysdeps/arc/configure. I tried all possibe autoconf cmds with toggles (both at top and in sysdeps/arc) and even reran configure in build tree with --enable-maintainer-mode >> Right, we've had 2 ARC ISA: current generation ARCv2 (basis for HS3x and HS4x >> processors) and the older ARCompact (ARC700 cores which run Linux and still >> supported e.g. in Mellanox NPS cores). From instruction set pov they are very >> similar (although not binary compatible). > > If they're not binary compatible (so you can't have a binary that works on > both) that indicates they should also be considered separate ABIs (so you > have four dynamic linker names, each with corresponding build in > build-many-glibcs.py, plus any other variants that are relevant to build > in build-many-glibcs.py without being different ABIs, such as hard/soft > float). I'll drop ARC700 support for now and we can add it later if need be. I suppose there are no other ABI/versioning/compat complications in such an approach. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 15/15] Documentation for ARC port
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote: > +* Support for ARC HS cores running Linux has been contributed by Synopsys. > + > + Port requires atleast > +- binutils-2.32 (binutils-2_31-branch: commit 6ce881c15fc4, 2018-10-04) > +- gcc 8.3 (gcc-8-stable: commit 0d5ba57508c5, 2019-01-29) > +- Linux kernel 5.1+ > + > + ISA: ARCv2 > + ABI: 32-bit, soft-float, LE: /lib/ld-linux-arc.so.2 (compatible with > + hard-float builds) I don't think the default of the dynamic linker name etc. (which should go on https://sourceware.org/glibc/wiki/ABIList) belong in the NEWS entry. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 13/15] ARC: Build Infrastructure
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> +ifeq ($(subdir),debug)
> +CFLAGS-backtrace.c += -funwind-tables
> +endif
debug/Makefile already has
CFLAGS-backtrace.c += -fno-omit-frame-pointer -funwind-tables
so you shouldn't need this.
> +++ b/sysdeps/arc/Versions
> @@ -0,0 +1,6 @@
> +libc {
> + GLIBC_2.32 {
> +__syscall_error;
Why does __syscall_error need a public symbol version? If it's used by a
library other than libc, that means it needs to be exported at some symbol
version - but it only needs a public version (as opposed to GLIBC_PRIVATE)
if it might be used by user programs linked with glibc (if it's used in
crt*.o, lib*_nonshared.a, or inline functions in installed headers, for
example - or in libgcc.a, libstdc++.a, etc. (GCC static libraries)).
> + gccfloat=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | grep __ARC_FPU_| wc
> -l`
> + if test "$gccfloat" != "0"; then
> +echo "glibc being configured for double precision floating point"
preconfigure fragments should not print this sort of debugging message
with "echo". If you feel such a message is important, use preconfigure.ac
and print it with AC_MSG_NOTICE.
--
Joseph S. Myers
jos...@codesourcery.com
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 11/15] ARC: ABI lists
On 3/27/20 11:39 AM, Joseph Myers wrote:
> On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote:
>
>> Done now. FWIW regen-ulps simply barfs so these need to be hand edited.
> What exactly is the regen-ulps problem? It ought to be working for all
> ports.
PASS: glibcs-arc-linux-gnu check-compilers
PASS: glibcs-arc-linux-gnu rm
PASS: glibcs-arc-linux-gnu mkdir
PASS: glibcs-arc-linux-gnu configure
PASS: glibcs-arc-linux-gnu build
FAIL: glibcs-arc-linux-gnu install
pwd=`pwd`; \
python3 -B ../math/gen-libm-test.py -s $pwd/.. -m
~/upstream/build/glibcs/arc-linux-gnu/glibc/manual/libm-err-tmp
Traceback (most recent call last):
File "../math/gen-libm-test.py", line 686, in
main()
File "../math/gen-libm-test.py", line 674, in main
all_ulps = read_all_ulps(args.srcdir)
File "../math/gen-libm-test.py", line 262, in read_all_ulps
all_ulps[name].read(os.path.join(dirpath, 'libm-test-ulps'))
File "../math/gen-libm-test.py", line 166, in read
raise ValueError('bad ulps line: %s' % line)
ValueError: bad ulps line: idouble: 1
make[3]: *** [Makefile:105:
~/upstream/build/glibcs/arc-linux-gnu/glibc/manual/stamp-libm-err] Error 1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 07/15] ARC: hardware floating point support
On 3/27/20 11:37 AM, Joseph Myers wrote: > feupdateenv has to preserve the previously raised exceptions even in the > FE_DFL_ENV case. It's equivalent to > > exc = fetestexcept (FE_ALL_EXCEPT); > fesetenv (envp); > feraiseexcept (exc); Ok. >> In some places I have following: >> >> if (((fpcr >> __FPU_RND_SHIFT) & FE_DOWNWARD) != round) >> >> So FE_DOWNWARD (0x3) is used as mask, is that OK or would you rather see >> >> #define __FPU_RND_MASK 0x3 > > I think it's cleanest to have a separate define for the mask. OK. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 11/15] ARC: ABI lists
On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > Done now. FWIW regen-ulps simply barfs so these need to be hand edited. What exactly is the regen-ulps problem? It ought to be working for all ports. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 08/15] ARC: Linux Syscall Interface
On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > But in grep'ing I see a weird thing: SO_RCVTIMEO in user exposed > socket.h has a totally different value from socket-constants.h - how is > that supposed to work. The top-level bits/socket.h is only for OSes without their own bits/socket.h. Thus it's not currently used, as both Hurd and Linux have their own sysdeps version. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 07/15] ARC: hardware floating point support
On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote: > > The bits to enable exception traps look like dynamic control mode bits to > > me. In general fegetmode should only need to mask off bits on > > architectures where the same register has both control and status bits, > > not on architectures where those are separate registers and fegetmode / > > fesetmode can work with the whole control register. > > Yeah, looking back into my old dev branch, that is how I did it initially, but > then switched to current implementation to "make get/set mode functions > inter-operate with get/set round" - although there was no inter-calling > between > the two. We can go back to that implementation as it seems slightly better in > generated code, but I'm curious if it is wrong too fegetmode / fesetmode deal with the complete set of dynamic control modes, not just rounding modes. I don't think any masking or shifting is needed or appropriate in fegetmode / fesetmode. > Is following pseudo-code correct for semantics ? > > fesetenv(env) > >if FE_DFL_ENV > fpcr = _FPU_DEFAULT; > fpsr = _FPU_FPSR_DEFAULT; >else > fpcr = envp->__fpcr; > fpsr = envp->__fpsr; > > feupdateenv(env) > >if FE_DFL_ENV > fpcr = _FPU_DEFAULT; > fpsr = _FPU_FPSR_DEFAULT; >else > fpcr = envp->__fpcr; > fpsr |= envp->__fpsr; <-- this is different feupdateenv has to preserve the previously raised exceptions even in the FE_DFL_ENV case. It's equivalent to exc = fetestexcept (FE_ALL_EXCEPT); fesetenv (envp); feraiseexcept (exc); > In some places I have following: > > if (((fpcr >> __FPU_RND_SHIFT) & FE_DOWNWARD) != round) > > So FE_DOWNWARD (0x3) is used as mask, is that OK or would you rather see > > #define __FPU_RND_MASK 0x3 I think it's cleanest to have a separate define for the mask. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC] ARC: initial ftrace support
On Fri, 27 Mar 2020 18:53:55 +0300
Eugeniy Paltsev wrote:
> +
> +noinline void _mcount(unsigned long parent_ip)
> +{
> + unsigned long ip = (unsigned long)__builtin_return_address(0);
> +
> + if (unlikely(ftrace_trace_function != ftrace_stub))
> + ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> + NULL, NULL);
> +}
> +EXPORT_SYMBOL(_mcount);
So, ARCv2 allows the _mcount code to be written in C? Nice!
-- Steve
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[RFC] ARC: initial ftrace support
Add initial ftrace support for ARCv2. We add support only for
function tracer (the simplest, not dynamic one), however it is
prerequisite for dynamic function tracer and other complex
ones.
Signed-off-by: Eugeniy Paltsev
---
arch/arc/Kconfig | 1 +
arch/arc/include/asm/Kbuild | 1 -
arch/arc/include/asm/ftrace.h | 16
arch/arc/kernel/Makefile | 10 ++
arch/arc/kernel/ftrace.c | 27 +++
5 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arc/include/asm/ftrace.h
create mode 100644 arch/arc/kernel/ftrace.c
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index ff2a393b635c..4b8f750bd32b 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -48,6 +48,7 @@ config ARC
select PCI_SYSCALL if PCI
select PERF_USE_VMALLOC if ARC_CACHE_VIPT_ALIASING
select HAVE_ARCH_JUMP_LABEL if ISA_ARCV2 && !CPU_ENDIAN_BE32
+ select HAVE_FUNCTION_TRACER if ISA_ARCV2
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 1b505694691e..4e2f55bdf2ff 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -6,7 +6,6 @@ generic-y += div64.h
generic-y += dma-mapping.h
generic-y += emergency-restart.h
generic-y += extable.h
-generic-y += ftrace.h
generic-y += hardirq.h
generic-y += hw_irq.h
generic-y += irq_regs.h
diff --git a/arch/arc/include/asm/ftrace.h b/arch/arc/include/asm/ftrace.h
new file mode 100644
index ..92303e506edf
--- /dev/null
+++ b/arch/arc/include/asm/ftrace.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Author: Eugeniy Paltsev
+ */
+
+#ifndef __ASM_ARC_FTRACE_H
+#define __ASM_ARC_FTRACE_H
+
+extern void _mcount(unsigned long parent_ip);
+
+/* 3 instructions 1x 16 bit + 1x 32 bit */
+#define MCOUNT_INSN_SIZE 6
+
+#endif /* __ASM_ARC_FTRACE_H */
diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 75539670431a..42c9c4b1cabd 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -22,12 +22,22 @@ obj-$(CONFIG_ARC_METAWARE_HLINK)+= arc_hostlink.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
+
+obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o
+
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
+endif
+
obj-$(CONFIG_ARC_FPU_SAVE_RESTORE) += fpu.o
ifdef CONFIG_ISA_ARCOMPACT
CFLAGS_fpu.o += -mdpfp
endif
ifdef CONFIG_ARC_DW2_UNWIND
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_ctx_sw.o = $(CC_FLAGS_FTRACE)
+endif
CFLAGS_ctx_sw.o += -fno-omit-frame-pointer
obj-y += ctx_sw.o
else
diff --git a/arch/arc/kernel/ftrace.c b/arch/arc/kernel/ftrace.c
new file mode 100644
index ..a61edf52bfe2
--- /dev/null
+++ b/arch/arc/kernel/ftrace.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Author: Eugeniy Paltsev
+ */
+
+#include
+
+noinline void ftrace_stub(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *op, struct pt_regs *regs)
+{
+ /* do notning */
+}
+
+extern void (*ftrace_trace_function)(unsigned long, unsigned long,
+struct ftrace_ops*, struct pt_regs*);
+
+noinline void _mcount(unsigned long parent_ip)
+{
+ unsigned long ip = (unsigned long)__builtin_return_address(0);
+
+ if (unlikely(ftrace_trace_function != ftrace_stub))
+ ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
+ NULL, NULL);
+}
+EXPORT_SYMBOL(_mcount);
--
2.21.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests
On 03/27/2020 06:46 AM, Anshuman Khandual wrote:
On 03/26/2020 08:53 PM, Christophe Leroy wrote:
Le 26/03/2020 à 03:23, Anshuman Khandual a écrit :
On 03/24/2020 10:52 AM, Anshuman Khandual wrote:
This series adds more arch page table helper tests. The new tests here are
either related to core memory functions and advanced arch pgtable helpers.
This also creates a documentation file enlisting all expected semantics as
suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).
This series has been tested on arm64 and x86 platforms.
If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
appreciated. Thank you.
On powerpc 8xx (PPC32), I get:
[ 53.338368] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page
table helpers
[ 53.347403] [ cut here ]
[ 53.351832] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:647
debug_vm_pgtable+0x280/0x3f4
mm/debug_vm_pgtable.c:647 ?
With the following commits in place
53a8338ce (HEAD) Documentation/mm: Add descriptions for arch page table helper
5d4913fc1 mm/debug: Add tests validating arch advanced page table helpers
bcaf120a7 mm/debug: Add tests validating arch page table helpers for core
features
d6ed5a4a5 x86/memory: Drop pud_mknotpresent()
0739d1f8d mm/debug: Add tests validating architecture page table helpers
16fbf79b0 (tag: v5.6-rc7) Linux 5.6-rc7
I have:
facaa5eb5909 (HEAD -> helpers0) mm/debug: Add tests validating arch
advanced page table helpers
6389fed515fc mm/debug: Add tests validating arch page table helpers for
core features
dc14ecc8b94e mm/debug: add tests validating architecture page table helpers
c6624071c338 (origin/merge, merge) Automatic merge of branches 'master',
'next' and 'fixes' into merge
58e05c5508e6 Automatic merge of branches 'master', 'next' and 'fixes'
into merge
1b649e0bcae7 (origin/master, origin/HEAD) Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
origin is https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
I can't see your last patch in powerpc mailing list
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166237)
mm/debug_vm_pgtable.c:647 is here.
Line 647 is:
WARN_ON(!pte_same(pte, __swp_entry_to_pte(swp)));
#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot)
{
swp_entry_t swp;
pmd_t pmd; -> Line #647
pmd = pfn_pmd(pfn, prot);
swp = __pmd_to_swp_entry(pmd);
WARN_ON(!pmd_same(pmd, __swp_entry_to_pmd(swp)));
}
#else
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot) { }
#end
Did I miss something ?
[...]
Could you please point me to the exact test which is failing ?
[ 53.519778] Freeing unused kernel memory: 608K
So I assume that the system should have come till runtime just fine apart from
the above warning message because.
Yes it boots fine otherwise.
Christophe
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests
On 03/26/2020 08:53 PM, Christophe Leroy wrote:
>
>
> Le 26/03/2020 à 03:23, Anshuman Khandual a écrit :
>>
>>
>> On 03/24/2020 10:52 AM, Anshuman Khandual wrote:
>>> This series adds more arch page table helper tests. The new tests here are
>>> either related to core memory functions and advanced arch pgtable helpers.
>>> This also creates a documentation file enlisting all expected semantics as
>>> suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).
>>>
>>> This series has been tested on arm64 and x86 platforms.
>>
>> If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
>> enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
>> appreciated. Thank you.
>>
>
> On powerpc 8xx (PPC32), I get:
>
> [ 53.338368] debug_vm_pgtable: debug_vm_pgtable: Validating architecture
> page table helpers
> [ 53.347403] [ cut here ]
> [ 53.351832] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:647
> debug_vm_pgtable+0x280/0x3f4
mm/debug_vm_pgtable.c:647 ?
With the following commits in place
53a8338ce (HEAD) Documentation/mm: Add descriptions for arch page table helper
5d4913fc1 mm/debug: Add tests validating arch advanced page table helpers
bcaf120a7 mm/debug: Add tests validating arch page table helpers for core
features
d6ed5a4a5 x86/memory: Drop pud_mknotpresent()
0739d1f8d mm/debug: Add tests validating architecture page table helpers
16fbf79b0 (tag: v5.6-rc7) Linux 5.6-rc7
mm/debug_vm_pgtable.c:647 is here.
#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot)
{
swp_entry_t swp;
pmd_t pmd; -> Line #647
pmd = pfn_pmd(pfn, prot);
swp = __pmd_to_swp_entry(pmd);
WARN_ON(!pmd_same(pmd, __swp_entry_to_pmd(swp)));
}
#else
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot) { }
#end
Did I miss something ?
> [ 53.360140] CPU: 0 PID: 1 Comm: swapper Not tainted
> 5.6.0-rc7-s3k-dev-01090-g92710e99881f #3544
> [ 53.368718] NIP: c0777c04 LR: c0777bb8 CTR:
> [ 53.373720] REGS: c9023df0 TRAP: 0700 Not tainted
> (5.6.0-rc7-s3k-dev-01090-g92710e99881f)
> [ 53.382042] MSR: 00029032 CR: 22000222 XER: 2000
> [ 53.388667]
> [ 53.388667] GPR00: c0777bb8 c9023ea8 c612 0001 1e41
> 007641c9
> [ 53.388667] GPR08: 0001 82000222
> c00039b8
> [ 53.388667] GPR16: fff0 065fc000 1e41
> c660 01e4
> [ 53.388667] GPR24: 01d9 c062d14c c65fc000 c642d448 06c9
> c65f8000 c65fc040
> [ 53.423400] NIP [c0777c04] debug_vm_pgtable+0x280/0x3f4
> [ 53.428559] LR [c0777bb8] debug_vm_pgtable+0x234/0x3f4
> [ 53.433593] Call Trace:
> [ 53.436048] [c9023ea8] [c0777bb8] debug_vm_pgtable+0x234/0x3f4 (unreliable)
> [ 53.442936] [c9023f28] [c00039e0] kernel_init+0x28/0x124
> [ 53.448184] [c9023f38] [c000f174] ret_from_kernel_thread+0x14/0x1c
> [ 53.454245] Instruction dump:
> [ 53.457180] 41a20008 4bea3ed9 62890021 7d36b92e 7d36b82e 71290fd0 3149
> 7d2a4910
> [ 53.464838] 0f09 5789077e 3149 7d2a4910 <0f09> 38c0
> 38a0 3880
> [ 53.472671] ---[ end trace fd5dd92744dc0065 ]---
Could you please point me to the exact test which is failing ?
> [ 53.519778] Freeing unused kernel memory: 608K
>
>
So I assume that the system should have come till runtime just fine apart from
the above warning message because.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
