I can confirm this patch set fixes an issue that guest kdump kernel
crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
when applying this patch set to latest kernel i.e. 6.0.0-rc1).
Tested-by: Coiby Xu
Previously, the issue can be reproduced as follows,
1. revert commit 7c5ed
On Mon, Aug 15, 2022 at 02:48:13PM +0800, Coiby Xu wrote:
I can confirm this patch set fixes an issue that guest kdump kernel
crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
when applying this patch set to latest kernel i.e. 6.0.0-rc1).
FYI, here's the error of applying it
From: Christophe Leroy
Since commit 591b4b268435 ("powerpc/code-patching: Pre-map patch area")
the patch area is premapped so intermediate page tables are already
allocated.
Use __set_pte_at() directly instead of the heavy map_kernel_page(),
at for unmapping just do a pte_clear() followed by a f
On 8/15/22 02:48, Coiby Xu wrote:
I can confirm this patch set fixes an issue that guest kdump kernel
crashes on POWER9 host by applying it to 5.19.1 (there is a conflict
when applying this patch set to latest kernel i.e. 6.0.0-rc1)
I rebased it. 2 of the borrowed patches disappeared now sin
From: Zi Yan
This Kconfig option is used by individual arch to set its desired
MAX_ORDER. Rename it to reflect its actual use.
Acked-by: Mike Rapoport
Signed-off-by: Zi Yan
Cc: Vineet Gupta
Cc: Shawn Guo
Cc: Taichi Sugaya
Cc: Neil Armstrong
Cc: Qin Jian
Cc: Catalin Marinas
Cc: Guo Ren
C
For csky part
Acked-by: Guo Ren
On Mon, Aug 15, 2022 at 10:40 PM Zi Yan wrote:
>
> From: Zi Yan
>
> This Kconfig option is used by individual arch to set its desired
> MAX_ORDER. Rename it to reflect its actual use.
>
> Acked-by: Mike Rapoport
> Signed-off-by: Zi Yan
> Cc: Vineet Gupta
> Cc
On Mon, Aug 15, 2022 at 4:39 PM Zi Yan wrote:
>
> ---
> arch/arc/Kconfig | 2 +-
> arch/arm/Kconfig | 2 +-
> arch/arm/configs/imx_v6_v7_defconfig | 2 +-
> arch/arm/configs/milbeaut_m10v_defconfig | 2 +-
> arch/arm/configs/oxna
On Mon, 15 Aug 2022, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.0-rc1[1] compared to v5.19[2].
Summarized:
- build errors: +26/-15
+ /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc
without corresponding .cf
It is better to use "unsigned int" instead of "unsigned", line 24.
Signed-off-by: Xin Gao
---
arch/powerpc/boot/epapr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/epapr.c b/arch/powerpc/boot/epapr.c
index 7c5b26ade6c4..4133bee28673 100644
--- a/arch/pow
On Mon, Aug 15, 2022 at 04:55:50PM +1000, Michael Ellerman wrote:
> The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
> warning on some systems:
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:580
> in_atomic(): 1, irqs_disabled(): 0, non_blo
From: Kent Overstreet
This converts from seq_buf to printbuf. We're using printbuf in external
buffer mode, so it's a direct conversion, aside from some trivial
refactoring in cpu_show_meltdown() to make the code more consistent.
Signed-off-by: Kent Overstreet
Cc: linuxppc-dev@lists.ozlabs.org
https://bugzilla.kernel.org/show_bug.cgi?id=216367
Bug ID: 216367
Summary: Kernel 6.0-rc1 fails to build with
GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G5 11,2)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 6.0-rc1
https://bugzilla.kernel.org/show_bug.cgi?id=216095
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301576
--> https://bugzilla.kernel.org/attachment.cgi?id=301576&action=edit
dmesg (6.0-rc1, PowerMac G5 11,2)
Still a problem in 6.0-rc1:
[...]
sysfs: cannot create du
https://bugzilla.kernel.org/show_bug.cgi?id=216095
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301577
--> https://bugzilla.kernel.org/attachment.cgi?id=301577&action=edit
kernel .config (6.0-rc1, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=216368
Bug ID: 216368
Summary: do_IRQ: stack overflow at boot on a PowerMac G5 11,2
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 6.0-rc1
Hardware: PPC-64
OS: L
https://bugzilla.kernel.org/show_bug.cgi?id=216368
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301579
--> https://bugzilla.kernel.org/attachment.cgi?id=301579&action=edit
dmesg (kernel 6.0-rc1, PowerMac G5 11,2), 2nd time
--
You may reply to this email to add a
https://bugzilla.kernel.org/show_bug.cgi?id=216368
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301580
--> https://bugzilla.kernel.org/attachment.cgi?id=301580&action=edit
kernel .config (kernel 6.0-rc1, PowerMac G5 11,2)
--
You may reply to this email to add a c
https://bugzilla.kernel.org/show_bug.cgi?id=216095
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #301577|0 |1
is obsolete|
Based on the original work from Sam Bobroff.
Give a unique ID to each recovery event, to ease log parsing
and prepare for parallel recovery.
Also add some new messages with a very simple format that may
be useful to log-parsers.
Signed-off-by: Ganesh Goudar
---
arch/powerpc/include/asm/eeh_eve
Hi,
EEH reocvery is currently serialized and these patches shorten
the time taken for EEH recovery by making the recovery to run
in parallel. The original author of these patches is Sam Bobroff,
I have rebased and tested these patches.
On powervm with 64 VFs and I see approximately 48% reduction
Based on the original work from Sam Bobroff.
There is currently little synchronization between EEH error detection
(eeh_dev_check_failure()), EEH error recovery
(eeh_handle_{normal,special}_event()) and the PCI subsystem (device
addition and removal), and so there are race conditions that lead to
Based on the original work from Sam Bobroff.
Currently, EEH recovery is entirely serialized and takes place within
a single kernel thread. This can cause recovery to take a long time
when there are many devices.
To shorten recovery time, this change allows recovery to proceed in
parallel in two w
Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and
node_random()") refactored some code by moving node_random() from
lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
include random.h, which conditionally defines add_latent_entropy()
depending on whether the macro
https://bugzilla.kernel.org/show_bug.cgi?id=216367
Andrew Donnellan (a...@linux.ibm.com) changed:
What|Removed |Added
CC||a...@linux.ibm.com
Le 15/08/2022 à 21:53, Xin Gao a écrit :
> It is better to use "unsigned int" instead of "unsigned", line 24.
The Subject in wrong: It is not a treewide patch but only a powerpc
patch as far as I understand.
Christophe
>
> Signed-off-by: Xin Gao
> ---
> arch/powerpc/boot/epapr.c | 2 +-
>
On Mon, Aug 15, 2022 at 4:40 PM Zi Yan wrote:
> From: Zi Yan
>
> This Kconfig option is used by individual arch to set its desired
> MAX_ORDER. Rename it to reflect its actual use.
>
> Acked-by: Mike Rapoport
> Signed-off-by: Zi Yan
> arch/m68k/Kconfig.cpu| 2 +-
Acked
26 matches
Mail list logo
