From: Marc Zyngier <maz@kernel.org>
To: Tim Harvey <tharvey@gateworks.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Robert Richter <rrichter@marvell.com>,
Will Deacon <will@kernel.org>,
Sunil Goutham <sgoutham@marvell.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: ARM64_SW_TTBR0_PAN enabled causing hangs on OcteonTX
Date: Tue, 25 Feb 2020 00:50:15 +0000 [thread overview]
Message-ID: <f732995ffdbcde8d0d0935d68dc0d5a2@kernel.org> (raw)
In-Reply-To: <CAJ+vNU3mhhFbE6ZZTNUbnQVLAepffzba9Dsm4uwccQ_cH8RrtA@mail.gmail.com>
Tim,
On 2020-02-25 00:35, Tim Harvey wrote:
> Greetings,
>
> I'm trying to understand why enabling CONFIG_ARM64_SW_TTBR0_PAN on an
> OcteonTX (CN80XX) SoC would cause the kernel to hang.
>
> Here's what I'm seeing using arch/arm64/defconfig +
> CONFIG_ARM64_SW_TTBR0_PAN=y on a Gateworks Newport board with a
> CN8030-1500BG676-SCP-P12-G SoC using the Marvell SDK-10.1.1.0 boot
> firmware:
>
> Starting kernel ...
>
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x430f0a22]
> [ 0.000000] Linux version 5.5.0-00001-g2028a3b (tharvey@tharvey)
> (gcc version 7.3.0 (Marvell Inc. Version: Marvell GCC7 build 238.0))
> #2 SMP PREEMPT Mon Feb 24 16:20:24 PST 2020
> [ 0.000000] Machine model: Gateworks Newport CN80XX GW6404
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] cma: Reserved 64 MiB at 0x000000007c000000
> [ 0.000000] NUMA: NODE_DATA [mem 0x7bbe5100-0x7bbe6fff]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000500000-0x000000003fffffff]
> [ 0.000000] DMA32 [mem 0x0000000040000000-0x000000007fffffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000500000-0x000000007fffffff]
> [ 0.000000] Initmem setup node 0 [mem
> 0x0000000000500000-0x000000007fffffff]
> [ 0.000000] On node 0 totalpages: 523008
> [ 0.000000] DMA zone: 4076 pages used for memmap
> [ 0.000000] DMA zone: 0 pages reserved
> [ 0.000000] DMA zone: 260864 pages, LIFO batch:63
> [ 0.000000] DMA32 zone: 4096 pages used for memmap
> [ 0.000000] DMA32 zone: 262144 pages, LIFO batch:63
> [ 0.000000] psci: probing for conduit method from DT.
> [ 0.000000] psci: PSCIv1.1 detected in firmware.
> [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] psci: Trusted OS resident on physical CPU 0x0
> [ 0.000000] psci: SMC Calling Convention v1.1
> [ 0.000000] percpu: Embedded 22 pages/cpu s53016 r8192 d28904 u90112
> [ 0.000000] pcpu-alloc: s53016 r8192 d28904 u90112 alloc=22*4096
> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [ 0.000000] Detected VIPT I-cache on CPU0
> [ 0.000000] CPU features: detected: GIC system register CPU
> interface
> [ 0.000000] CPU features: detected: Cavium erratum 30115
> [ 0.000000] CPU features: detected: Kernel page table isolation
> (KPTI)
If this CPU is just another version of TX1, KPTI shouldn't get enabled
on
this HW, as it definitely breaks (see erratum 27456 and its
consequences).
Can you please enable CONFIG_CAVIUM_ERRATUM_27456 and report back?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-25 0:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 0:35 ARM64_SW_TTBR0_PAN enabled causing hangs on OcteonTX Tim Harvey
2020-02-25 0:50 ` Marc Zyngier [this message]
2020-02-25 1:16 ` Tim Harvey
2020-02-25 1:55 ` Marc Zyngier
2020-02-25 16:13 ` Tim Harvey
2020-02-25 16:27 ` Marc Zyngier
2020-02-25 16:35 ` Robert Richter
2020-02-25 17:00 ` Marc Zyngier
2020-02-25 17:04 ` Tim Harvey
2020-02-25 17:19 ` Marc Zyngier
2020-02-25 17:29 ` Tim Harvey
2020-02-25 17:47 ` Marc Zyngier
2020-02-25 17:11 ` Tim Harvey
2020-03-10 14:51 ` Tim Harvey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f732995ffdbcde8d0d0935d68dc0d5a2@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=rrichter@marvell.com \
--cc=sgoutham@marvell.com \
--cc=tharvey@gateworks.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).