https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #4 from Christophe Leroy (christophe.le...@csgroup.eu) ---
This problem was introduced in 5.15 by commit 602946ec2f90 ("powerpc: Set
max_mapnr correctly")
A similar issue has been opened at
https://github.com/linuxppc/issues/issues/39
On Thu, 31 Mar 2022 at 02:05, Murilo Opsfelder Araújo
wrote:
>
> Hi, Joel.
>
> On 3/30/22 08:24, Joel Stanley wrote:
> > Currently the boot wrapper lacks a -mcpu option, so it will be built for
> > the toolchain's default cpu. This is a problem if the toolchain defaults
> > to a cpu with newer ins
Hi, Joel.
On 3/30/22 08:24, Joel Stanley wrote:
Currently the boot wrapper lacks a -mcpu option, so it will be built for
the toolchain's default cpu. This is a problem if the toolchain defaults
to a cpu with newer instructions.
We could wire in TARGET_CPU but instead use the oldest supported op
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300667
--> https://bugzilla.kernel.org/attachment.cgi?id=300667&action=edit
kernel .config (5.15.32, PowerMac G4 DP)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300666
--> https://bugzilla.kernel.org/attachment.cgi?id=300666&action=edit
kernel .config (5.16.18, PowerMac G4 DP)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300665
--> https://bugzilla.kernel.org/attachment.cgi?id=300665&action=edit
dmesg (5.15.32, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You are r
https://bugzilla.kernel.org/show_bug.cgi?id=215781
Bug ID: 215781
Summary: Highmem support broken on kernels greater 5.15.x on
ppc32?
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.16.18
Hardware: PP
On Wed, 30 Mar 2022 06:55:26 +
Christophe Leroy wrote:
> > Small nit. Please order the includes in "upside-down x-mas tree" fashion:
> >
> > #include
> > #include
> > #include
> > #include
> >
>
> That's the first time I get such a request. Usually people request
> #includes to be i
On 3/29/22 1:31 AM, Kai-Heng Feng wrote:
On some Intel AlderLake platforms, Thunderbolt entering D3cold can cause
some errors reported by AER:
[ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error
received: :00:1d.0
[ 30.100251] pcieport :00:1d.0: PCIe Bus Error:
Christophe Leroy wrote:
Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
Josh Poimboeuf writes:
On Sun, Mar 27, 2022 at 09:09:20AM +, Christophe Leroy wrote:
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait
The pull request you sent on Tue, 29 Mar 2022 13:54:41 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/libnvdimm-for-5.18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ee96dd9614f1c139e719dd2f296acbed7f1ab4b8
Thank you!
--
Deet-doot-dot
On Thu, Mar 31, 2022 at 12:21:03AM +1100, Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> >> Linus Torvalds writes:
> >> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
> >> > wrote:
> >>
> >> > That said:
> >> >
> >>
On Tue, 29 Mar 2022 18:43:27 +0200
David Hildenbrand wrote:
> Let's use bit 52, which is unused.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s390/include/asm/pgtable.h | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/include/asm
On Tue, 29 Mar 2022 18:43:26 +0200
David Hildenbrand wrote:
> Bit 52 and bit 55 don't have to be zero: they only trigger a
> translation-specifiation exception if the PTE is marked as valid, which
> is not the case for swap ptes.
>
> Document which bits are used for what, and which ones are unus
On Wed, Mar 30, 2022 at 3:21 PM Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> >> No you're right, we have moved away from them, but not entirely.
> >>
> >> Functions descriptors are still used for 64-bit big endian, but t
From: Nicholas Piggin
emulate_step() instruction emulation including sc instruction emulation
initially appeared in xmon. It was then moved into sstep.c where kprobes
could use it too, and later hw_breakpoint and uprobes started to use it.
Until uprobes, the only instruction emulation users were
Per the ISA, a Trace interrupt is not generated for:
- [h|u]rfi[d]
- rfscv
- sc, scv, and Trap instructions that trap
- Power-Saving Mode instructions
- other instructions that cause interrupts (other than Trace interrupts)
- the first instructions of any interrupt handler (applies to Branch and Si
Some of the primary opcodes are duplicated. Remove those, and sort the
rest of the primary opcodes to make it easy to read.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/ppc-opcode.h | 69 ---
1 file changed, 31 insertions(+), 38 deletions(-)
diff --git a/arc
Since v1, the main change is to use helpers to decode primary/extended
opcode and the addition of macros for some of the used opcodes.
- Naveen
Naveen N. Rao (2):
powerpc: Sort and de-dup primary opcodes in ppc-opcode.h
powerpc: Reject probes on instructions that can't be single stepped
N
On Wed, Mar 30, 2022 at 07:21:23PM +0530, Srikar Dronamraju wrote:
> With commit 09f49dca570a ("mm: handle uninitialized numa nodes
> gracefully") NODE_DATA for even a memoryless/cpuless node is partially
> initialized at boot time.
>
> Before onlining the node, current Powerpc code checks for NOD
With commit 09f49dca570a ("mm: handle uninitialized numa nodes
gracefully") NODE_DATA for even a memoryless/cpuless node is partially
initialized at boot time.
Before onlining the node, current Powerpc code checks for NODE_DATA to
be NULL. However since NODE_DATA is partially initialized, this che
Michal Suchánek writes:
> On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
>> Linus Torvalds writes:
>> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
>> > wrote:
>>
>> > That said:
>> >
>> >> There's a series of commits cleaning up function descriptor handling,
>> >
>> >
Christophe Leroy wrote:
Le 28/03/2022 à 19:20, Naveen N. Rao a écrit :
Michael Ellerman wrote:
Murilo Opsfelder Araújo writes:
On 3/23/22 08:51, Naveen N. Rao wrote:
+static inline bool can_single_step(u32 inst)
+{
+ switch (inst >> 26) {
Can't ppc_inst_primary_opcode() be used instea
On 29/03/2022, 13:14:10, Michael Ellerman wrote:
> Laurent Dufour writes:
>> On 29/03/2022, 10:31:33, Nicholas Piggin wrote:
>>> Excerpts from Laurent Dufour's message of March 17, 2022 9:06 pm:
RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
mode (MSR[SF] unset).
>
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I
On Wed, 30 Mar 2022 at 11:33, Christophe Leroy
wrote:
>
>
>
> Le 30/03/2022 à 13:24, Joel Stanley a écrit :
> > Currently the boot wrapper lacks a -mcpu option, so it will be built for
> > the toolchain's default cpu. This is a problem if the toolchain defaults
> > to a cpu with newer instructions
On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> Linus Torvalds writes:
> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
> > wrote:
>
> > That said:
> >
> >> There's a series of commits cleaning up function descriptor handling,
> >
> > For some reason I also thought that
Le 30/03/2022 à 13:24, Joel Stanley a écrit :
> Currently the boot wrapper lacks a -mcpu option, so it will be built for
> the toolchain's default cpu. This is a problem if the toolchain defaults
> to a cpu with newer instructions.
>
> We could wire in TARGET_CPU but instead use the oldest suppo
Currently the boot wrapper lacks a -mcpu option, so it will be built for
the toolchain's default cpu. This is a problem if the toolchain defaults
to a cpu with newer instructions.
We could wire in TARGET_CPU but instead use the oldest supported option
so the wrapper runs anywhere.
The GCC documen
Le 29/03/2022 à 00:31, Joel Stanley a écrit :
> On Mon, 29 Nov 2021 at 22:43, Christophe Leroy
> wrote:
>>
>>
>>
>> Le 29/11/2021 à 18:43, Steven Rostedt a écrit :
>>> On Fri, 26 Nov 2021 08:43:23 +
>>> LEROY Christophe wrote:
>>>
Le 24/11/2021 à 15:43, Christophe Leroy a écrit :
>
allmodconfig
powerpc randconfig-c003-20220330
i386 randconfig-c001
sh rts7751r2d1_defconfig
armrealview_defconfig
arm assabet_defconfig
alpha defconfig
ftrace_graph_is_dead() is used on hot paths, it just reads a variable
in memory and is not worth suffering function call constraints.
For instance, at entry of prepare_ftrace_return(), inlining it avoids
saving prepare_ftrace_return() parameters to stack and restoring them
after calling ftrace_gra
35 matches
Mail list logo
