power_save_ppc32_restore() is called during exception entry, before
re-enabling the MMU. It substracts KERNELBASE from the address
of nap_save_msscr0 to access it.
With CONFIG_VMAP_STACK enabled, data MMU translation has already been
re-enabled, so power_save_ppc32_restore() has to access
nap_save
Le 13/02/2020 à 11:04, Christophe Leroy a écrit :
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in th
Larry,
Le 14/02/2020 à 00:09, Larry Finger a écrit :
Christophe,
With this patch, it gets further. Sometime after the boot process tries
to start process init, it crashes with the unable to read data at
0x000157a0 with a faulting address of 0xc001683c. The screenshot is
attached and the gzip
Dan Williams writes:
> On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> > The "sub-section memory hotplug" facility allows memremap_pages() users
>> > like libnvdimm to compensate for hardware platforms like x86 that have a
>> > section size larger than their h
On 13/2/20 4:23 pm, Daniel Axtens wrote:
kcov instrumentation is collected the __sanitizer_cov_trace_pc hook in
kernel/kcov.c. The compiler inserts these hooks into every basic block
unless kcov is disabled for that file.
We then have a deep call-chain:
- __sanitizer_cov_trace_pc calls to chec
PowerVM systems running compatibility mode on a few Power8 revisions are
still vulnerable to the hardware defect that loses PMU exceptions arriving
prior to a context switch.
The software fix for this issue is enabled through the CPU_FTR_PMAO_BUG
cpu_feature bit, nevertheless this bit also needs t
Hi Segher,
Thanks a lot for reviewing it.
On 02/13/2020 08:31 PM, Segher Boessenkool wrote:
---
arch/powerpc/kvm/book3s_hv_tm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
index 0db937497169..d3
On Thu, Feb 13, 2020 at 10:15:32AM -0500, Gustavo Romero wrote:
> On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
> KVM. This is handled at first by the hardware raising a softpatch interrupt
> when certain TM instructions that need KVM assistance are executed in the
> g
On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The pmem driver on PowerPC crashes with the following signature when
> > instantiating misaligned namespaces that map their capacity via
> > memremap_pages().
> >
> > BUG: Unable to handle kernel data access at 0
Dan Williams writes:
> The pmem driver on PowerPC crashes with the following signature when
> instantiating misaligned namespaces that map their capacity via
> memremap_pages().
>
> BUG: Unable to handle kernel data access at 0xc00100040600
> Faulting instruction address: 0xc0
> -Original Message-
> From: Rasmus Villemoes
> Sent: Thursday, February 13, 2020 5:44 AM
> To: Greg Kroah-Hartman ; Jiri Slaby
> ; Timur Tabi ; Leo Li
> ; Rasmus Villemoes
> Cc: Qiang Zhao ; linuxppc-dev@lists.ozlabs.org; Scott
> Wood ; Christophe Leroy ;
> linux-ser...@vger.kernel.or
Dan Williams writes:
> The "sub-section memory hotplug" facility allows memremap_pages() users
> like libnvdimm to compensate for hardware platforms like x86 that have a
> section size larger than their hardware memory mapping granularity. The
> compensation that sub-section support affords is b
https://bugzilla.kernel.org/show_bug.cgi?id=206527
Bug ID: 206527
Summary: Kernel 5.6-rc1 w. CONFIG_VMAP_STACK=y + CONFIG_KASAN=y
fails to boot on a PowerMac G4 3,6
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version:
Dan Williams writes:
> The pmem driver on PowerPC crashes with the following signature when
> instantiating misaligned namespaces that map their capacity via
> memremap_pages().
>
> BUG: Unable to handle kernel data access at 0xc00100040600
> Faulting instruction address: 0xc0
Dan Williams writes:
> @@ -312,8 +312,9 @@ static ssize_t flags_show(struct device *dev,
> {
> struct nvdimm *nvdimm = to_nvdimm(dev);
>
> - return sprintf(buf, "%s%s\n",
> + return sprintf(buf, "%s%s%s\n",
> test_bit(NDD_ALIASING, &nvdimm->flags) ? "alias "
https://bugzilla.kernel.org/show_bug.cgi?id=206525
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 287359
--> https://bugzilla.kernel.org/attachment.cgi?id=287359&action=edit
kernel .config (5.6.0-rc1, PowerMac G4 DP)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206525
Bug ID: 206525
Summary: BUG: KASAN: stack-out-of-bounds in test_bit+0x30/0x44
(kernel 5.6-rc1)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.6.0-rc1
On Thu, Feb 13, 2020 at 12:43:42PM +0100, Rasmus Villemoes wrote:
> Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
> out I was wrong about nobody relying on the lazy initialization of the
> cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy
> call of cpm_mu
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
Sure. Thanks!
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The "sub-section memory hotplug" facility allows memremap_pages() users
> > like libnvdimm to compensate for hardware platforms like x86 that have a
> > section size larger than their hardware memory mapping granular
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #9 from Christophe Leroy (christophe.le...@c-s.fr) ---
Great. Can we add your Tested-by: to the commit ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
POWER9P PVR bits are same as that of POWER9. Hence mask off only the
relevant bits for the major revision similar to POWER9.
Without this patch the cpuinfo output shows 17.0 as revision:
$ cat /proc/cpuinfo
processor : 0
cpu : POWER9P, altivec supported
clock : 2950.00
On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Some TM instructions, although not defined in the Power ISA, might
On 02/13/2020 02:28 PM, Larry Finger wrote:
On 2/11/20 1:23 PM, Christophe Leroy wrote:
Can you send me a picture of that BUG Unable to handle kernel data
access with all the registers values etc..., together with the
matching vmlinux ?
First thing is to identify where we are when that happ
Le 13/02/2020 à 12:43, Rasmus Villemoes a écrit :
Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
out I was wrong about nobody relying on the lazy initialization of the
cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy
call of cpm_muram_init()).
Rathe
Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
out I was wrong about nobody relying on the lazy initialization of the
cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy
call of cpm_muram_init()).
Rather than reinstating the somewhat dubious lazy call (init
Le 13/02/2020 à 01:47, Daniel Axtens a écrit :
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 497b7d0b2d7e..f1c54c08a88e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -169,7 +169,9 @@ config PPC
select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #7)
> Can you try version v2 of the patch,
> https://patchwork.ozlabs.org/patch/1237387/
I can confirm that v2 works as intended. The G4 completes
On 02/12/2020 11:02 PM, Larry Finger wrote:
On 2/11/20 1:23 PM, Christophe Leroy wrote:
Can you send me a picture of that BUG Unable to handle kernel data
access with all the registers values etc..., together with the
matching vmlinux ?
The vmlinux file was too big for your mailbox. You
Le 12/02/2020 à 09:04, afzal mohammed a écrit :
request_irq() is preferred over setup_irq(). Existing callers of
setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
memory allocators are ready by 'mm_init()'.
Per tglx[1], setup_irq() existed in olden days when allocators were n
Le 13/02/2020 à 10:37, Rasmus Villemoes a écrit :
On 12/02/2020 15.50, Christophe Leroy wrote:
On 02/12/2020 02:24 PM, Christophe Leroy wrote:
In your commit text you explain that cpm_muram_init() is called via
subsys_initcall. But console init is done before that, so it cannot work.
Do
https://bugzilla.kernel.org/show_bug.cgi?id=206501
--- Comment #7 from Christophe Leroy (christophe.le...@c-s.fr) ---
Can you try version v2 of the patch,
https://patchwork.ozlabs.org/patch/1237387/
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 02/13/2020 07:45 AM, Rasmus Villemoes wrote:
On 12/02/2020 15.24, Christophe Leroy wrote:
Hi Rasmus,
Kernel 5.6-rc1 silently fails on boot.
I bisected the problem to commit b6231ea2b3c6 ("soc: fsl: qe: drop
broken lazy call of cpm_muram_init()")
I get a bad_page_fault() for an access at
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in the MMU hash table.
However, if the page where the page
The PowerPC time code is not a clock provider, and just needs to call
of_clk_init().
Hence it can include instead of .
Remove the #ifdef protecting the of_clk_init() call, as a stub is
available for the !CONFIG_COMMON_CLK case.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Stephen Boyd
---
v
On 12/02/2020 15.50, Christophe Leroy wrote:
>
>
> On 02/12/2020 02:24 PM, Christophe Leroy wrote:
>> In your commit text you explain that cpm_muram_init() is called via
>> subsys_initcall. But console init is done before that, so it cannot work.
>>
>> Do you have a fix for that ?
>>
>
> The fo
On 12.02.2020 20:09, Stephen Smalley wrote:
> On 2/12/20 11:56 AM, Alexey Budankov wrote:
>>
>>
>> On 12.02.2020 18:45, Stephen Smalley wrote:
>>> On 2/12/20 10:21 AM, Stephen Smalley wrote:
On 2/12/20 8:53 AM, Alexey Budankov wrote:
> On 12.02.2020 16:32, Stephen Smalley wrote:
>> O
37 matches
Mail list logo
