The pull request you sent on Sun, 16 May 2021 09:35:30 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.13-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/63d1cb53e26a9a4168b84a8981b225c0a9cfa235
Thank you!
--
Deet-doot-d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.13:
The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:
Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)
are available in the git repository at:
https://git.kernel.org/pu
On 5/15/21 1:41 PM, Andrew Morton wrote:
On Sat, 15 May 2021 09:35:25 -0700 Guenter Roeck wrote:
#define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
unsigned long start
On Sat, 8 May 2021 20:14:51 +1000, Nicholas Piggin wrote:
> This didn't seem to send properly, apologies if you get a duplicate.
>
> Patch 1 is the important fix. 2 might fix something, although I haven't
> provoked a crash yet.
>
> Patch 3 is a small cleanup, and patch 4 I think is the right thi
On Mon, 3 May 2021 21:17:08 +1000, Nicholas Piggin wrote:
> scv support introduced the notion of code that implicitly soft-masks
> irqs due to the instruction addresses. This is required because scv
> enters the kernel with MSR[EE]=1.
>
> If a NMI (including soft-NMI) interrupt hits when we are im
On Fri, 14 May 2021 14:40:08 +1000, Nicholas Piggin wrote:
> Some interrupt handlers have an "extra" that saves 1 or 2 registers
> (r14, r15) in the paca save area and makes them available to use by the
> handler.
>
> The change to always save nvgprs in exception handlers lead to some
> interrupt
On Thu, 6 May 2021 14:49:58 +1000, Michael Ellerman wrote:
> The STF (store-to-load forwarding) barrier mitigation can be
> enabled/disabled at runtime via a debugfs file (stf_barrier), which
> causes the kernel to patch itself to enable/disable the relevant
> mitigations.
>
> However depending on
On Tue, 11 May 2021 20:54:59 +1000, Michael Ellerman wrote:
> Commit 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based
> MMU notifier callbacks") fixed kvm_unmap_gfn_range_hv() by adding a for
> loop over each gfn in the range.
>
> But for the Hash MMU it repeatedly calls kvm_unmap_r
On Fri, 14 May 2021 00:07:59 +1000, Michael Ellerman wrote:
> The entry flush mitigation can be enabled/disabled at runtime. When this
> happens it results in the kernel patching its own instructions to
> enable/disable the mitigation sequence.
>
> With strict kernel RWX enabled instruction patchi
On Sat, 8 May 2021 09:25:32 + (UTC), Christophe Leroy wrote:
> Building kernel mainline with GCC 11 leads to following failure
> when starting 'init':
>
> init[1]: bad frame in sys_sigreturn: 7ff5a900 nip 001083cc lr 001083c4
> Kernel panic - not syncing: Attempted to kill init! exitcode=0
On Thu, 6 May 2021 11:56:31 + (UTC), Christophe Leroy wrote:
> kuap_save_and_lock() is only for interrupts inside kernel.
>
> system call are only from user, calling kuap_save_and_lock()
> is wrong.
Applied to powerpc/fixes.
[1/1] powerpc/syscall: Calling kuap_save_and_lock() is wrong
On Sat, 8 May 2021 09:25:44 + (UTC), Christophe Leroy wrote:
> When neither CONFIG_VSX nor CONFIG_PPC_FPU_REGS are selected,
> unsafe_copy_fpr_to_user() and unsafe_copy_fpr_from_user() are
> doing nothing.
>
> Then, unless the 'label' operand is used elsewhere, GCC complains
> about it being d
On Sat, 8 May 2021 06:36:21 + (UTC), Christophe Leroy wrote:
> UBSAN complains when a pointer is calculated with invalid
> 'legacy_serial_console' index, allthough the index is verified
> before dereferencing the pointer.
>
> Fix it by checking 'legacy_serial_console' validity before
> calcula
On Thu, 6 May 2021 14:49:45 + (UTC), Christophe Leroy wrote:
> Same as kuap_user_restore(), kuep_unlock() has to be called when
> really returning to user, that is in interrupt_exit_user_prepare(),
> not in interrupt_exit_prepare().
Applied to powerpc/fixes.
[1/1] powerpc/interrupts: Fix kuep
On Sat, 15 May 2021 09:35:25 -0700 Guenter Roeck wrote:
> >
> > #define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> > static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
>
> >unsigned long start, unsigned long end)
> > +{
> > +
On Thu, Apr 22, 2021 at 11:13:19AM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> .../include/asm/book3s/64/tlbflush-radix.h| 19 +++-
> arch/powerpc/include/asm/book3s/64/tlbflush.h | 23 ---
> arch/powerpc
https://bugzilla.kernel.org/show_bug.cgi?id=213079
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Kernel Version|5.13-rc1|5.12.3
Summ
On 15 May 2021 at 12:08pm Christophe Leroy wrote:
Le 15/05/2021 à 11:48, Christian Zigotzky a écrit :
Hi All,
I bisected today [1] and the bisecting itself was OK but the
reverting of the bad commit doesn't solve the issue. Do you have an
idea which commit could be resposible for this issue
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Hmm... Just also happened on 5.12.3. But without the Kernel panic (yet).
[...]
irq 63: nobody cared (try booting with the "irqpoll" option)
Call Trace:
CPU: 1 PID: 43491 Comm: emerge Tainte
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 296761
--> https://bugzilla.kernel.org/attachment.cgi?id=296761&action=edit
kernel .config (5.13-rc1, PowerMac G5 11,2)
--
You may reply to this email to add a comment
https://bugzilla.kernel.org/show_bug.cgi?id=213079
Bug ID: 213079
Summary: IRQ problems and crashes on a PowerMac G5 with
5.13-rc1
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.13-rc1
Hardware: PPC-
On Fri, 14 May 2021 21:51:51 +0100,
Thomas Gleixner wrote:
>
> On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
>
> CC: +Marc
Thanks Thomas.
>
> > PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
> > underlying calls handling the passthrough of the interrupt in the
>
https://bugzilla.kernel.org/show_bug.cgi?id=213069
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
The bug occurs with DEBUG_VM_PGTABLE=y. When DEBUG_VM_PGTABLE is not set the
kernel boots fine.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You a
Le 15/05/2021 à 11:48, Christian Zigotzky a écrit :
Hi All,
I bisected today [1] and the bisecting itself was OK but the reverting of the bad commit doesn't
solve the issue. Do you have an idea which commit could be resposible for this issue? Maybe the
bisecting wasn't successful. I will lo
Hi All,
I bisected today [1] and the bisecting itself was OK but the reverting
of the bad commit doesn't solve the issue. Do you have an idea which
commit could be resposible for this issue? Maybe the bisecting wasn't
successful. I will look in the kernel git log. Maybe there is a commit
that
On Sat, 2021-05-15 at 09:14 +0200, Pavel Machek wrote:
> On Sun 2021-05-02 00:15:38, Masahiro Yamada wrote:
> > The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> > GCC 5.1.
>
> Please don't. I'm still on 4.9 on machine I can't easily update,
Why is that? Later compiler version
On Sun 2021-05-02 00:15:38, Masahiro Yamada wrote:
> The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> GCC 5.1.
Please don't. I'm still on 4.9 on machine I can't easily update,
> Documentation/process/changes.rst | 2 +-
> arch/arm64/Kconfig| 2 +-
> arch/power
27 matches
Mail list logo
