On Thu, Apr 28, 2022 at 10:41:48PM +1000, Michael Ellerman wrote:
> Hi Greg,
>
> Here are two custom backports to v4.19 for some powerpc issues we've
> discovered.
> Both were fixed upstream as part of a large non-backportable rewrite. Other
> stable
> kernel versions are not affected.
>
> chee
This is a note to let you know that I've just added the patch titled
powerpc/64/interrupt: Temporarily save PPR on stack to fix register
corruption due to SLB miss
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=su
This is a note to let you know that I've just added the patch titled
powerpc/64s: Unmerge EX_LR and EX_DAR
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-64s-unme
Hello!
On 4/28/22 1:49 AM, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented
> through separate notifiers, one for die/oops and the other
> for panic. With the addition of panic notifier "id", this
> patch makes use of such "id" to unify both functions.
>
>
Nicholas Piggin writes:
> Excerpts from Nicholas Piggin's message of April 21, 2022 12:07 pm:
>> Excerpts from Michal Suchánek's message of April 21, 2022 12:28 am:
>>> Hello,
>>>
>>> On Thu, Apr 21, 2022 at 12:16:57AM +1000, Michael Ellerman wrote:
This is a partial revert of commit 0faf20a
Pali Rohár writes:
> Hello!
>
> I started playing with PowerPC e500 architecture, it is something really
> new for me and I suspect that I found a bug in U-Boot code which
> configures L2 cache as initial SRAM (L2 with locked lines).
>
> U-Boot code for the first half of L2 cache sets Caching-inhi
It is incorrect to use ptep_clear_flush() to nuke a hugetlb page
table when unmapping or migrating a hugetlb page, and will change
to use huge_ptep_clear_flush() instead in the following patches.
So this is a preparation patch, which changes the huge_ptep_clear_flush()
to return the original pte t
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When migrating a hugetlb page, we will get the relevant page table
entry by huge_p
Hi,
Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
use ptep_clear_flush() and set_pte_at() to nuke the page table entry
and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
page, which will cause potential data consistent issue. This patch set
will ch
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When unmapping a hugetlb page, we will get the relevant page table
entry by huge_p
On Friday 29 April 2022 22:57:03 Michael Ellerman wrote:
> Pali Rohár writes:
> > Hello!
> >
> > I started playing with PowerPC e500 architecture, it is something really
> > new for me and I suspect that I found a bug in U-Boot code which
> > configures L2 cache as initial SRAM (L2 with locked lin
On Fri, 29 Apr 2022 12:22:44 +0300
Sergei Shtylyov wrote:
> > + switch (ev) {
> > + case DIE_OOPS:
> > + do_dump = 1;
> > + break;
> > + case PANIC_NOTIFIER:
> > + do_dump = 1;
> > + break;
>
>Why not:
>
> case DIE_OOPS:
> case PAN
> On 28-Apr-2022, at 10:26 PM, Sachin Sant wrote:
>
> While running LTP tests (mmapstress03 specifically) against
> 5.18.0-rc4-next-20220428
> booted on IBM Power server mentioned BUG is encountered.
>
> # ./mmapstress03
> mmapstress030 TINFO : uname.machine=ppc64le kernel is 64bit
> m
On 29/04/2022 10:23, Steven Rostedt wrote:
> On Fri, 29 Apr 2022 12:22:44 +0300
> Sergei Shtylyov wrote:
>
>>> + switch (ev) {
>>> + case DIE_OOPS:
>>> + do_dump = 1;
>>> + break;
>>> + case PANIC_NOTIFIER:
>>> + do_dump = 1;
>>> + break;
>>
>>W
We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such suppo
On Fri, 29 Apr 2022 10:46:35 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Sergei and Steven, good idea! I thought about the switch change
> you propose, but I confess I got a bit confused by the "fallthrough"
> keyword - do I need to use it?
No. The fallthrough keyword is only needed when there'
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Thanks Helge, added!
Cheers,
Guilherme
>
>
>> ---
>> arch/parisc/include/asm/pdc.h | 1 +
>> arch/parisc/kernel/firmware.c | 27 +++
>> drivers/parisc/power.
On 29/04/2022 10:56, Steven Rostedt wrote:
> [...]
> No. The fallthrough keyword is only needed when there's code between case
> labels. As it is very common to list multiple cases for the same code path.
> That is:
>
> case DIE_OOPS:
> case PANIC_NOTIFIER:
> do_dump = 1;
Following powerpc builds failed on Linux next-20220428 and next-20220429.
Regressions found on powerpc:
- gcc-11-ppc64e_defconfig
- gcc-10-ppc64e_defconfig
- gcc-9-ppc64e_defconfig
- gcc-8-ppc64e_defconfig
- clang-14-ppc64e_defconfig
- clang-nightly-ppc64e_defconfig
- clang
On 27/04/2022 21:28, Randy Dunlap wrote:
>
>
> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>> +crash_kexec_post_notifiers
>> +This was DEPRECATED - users should always prefer the
>
> This is DEPRECATED - users should always prefer the
>
>> +
On Thu, Apr 28, 2022 at 05:31:38PM -0500, Nathan Lynch wrote:
> Bjorn Helgaas writes:
> > On Tue, Apr 26, 2022 at 11:07:39PM +0530, Mahesh Salgaonkar wrote:
> >> +/*
> >> + * RTAS call get-sensor-state(DR_ENTITY_SENSE) return values as per PAPR:
> >> + *-1: Hardware Error
> >> + *-2: RTAS_
Steven Rostedt wrote:
On Thu, 28 Apr 2022 22:49:52 +0530
"Naveen N. Rao" wrote:
But, with ppc64 elf abi v1 which only supports the old -pg flag, mcount
location can differ between the weak and non-weak variants of a
function. In such scenarios, one of the two mcount entries will be
invalid. Su
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
> [...]
> How would you like to proceed with queuing this ? I am happy
> either way. In case you plan to push this as part of this
> series (I don't see any potential conflicts) :
>
> Reviewed-by: Suzuki K Poulose
Thanks for your revi
Thanks Paul and Suzuki for the ACKs.
Cheers,
Guilherme
On 28/04/2022 13:26, Corey Minyard wrote:
> [...]
>
> For the IPMI portion:
>
> Acked-by: Corey Minyard
Thanks Alex and Corey for the ACKs!
>
> Note that the IPMI panic_event() should always return, but it may take
> some time, especially if the IPMI controller is no longer functional.
> So t
On Wed, Apr 27, 2022 at 3:55 PM Guilherme G. Piccoli
wrote:
>
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them not so e
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs, puttin
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently we have a debug infrastructure in the notifiers file, but
> it's very simple/limited. This patch extends it by:
>
> (a) Showing all registered/unregistered notifiers' callback names;
>
> (b) Adding a dynamic debug
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently Hyper-V guests are among the most relevant users of the panic
> infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
> both in cleaning-up procedures (closing a hypervisor <-> guest connection,
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> The goal of this new panic notifier is to allow its users to register
> callbacks to run very early in the panic path. This aims hypervisor/FW
> notification mechanisms as well as simple LED functions, and any other
> simple
-Original Message-
From: Athira Rajeev
To: a...@kernel.org, jo...@kernel.org, disg...@linux.vnet.ibm.com
Cc: m...@ellerman.id.au, linux-perf-us...@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, ma...@linux.vnet.ibm.com,
rnsas...@linux.ibm.com, kj...@linux.ibm.com, irog...@google.com
S
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> The panic() function is somewhat convoluted - a lot of changes were
> made over the years, adding comments that might be misleading/outdated
> now, it has a code structure that is a bit complex to follow, with
> lots of condi
On Fri, 29 Apr 2022 23:09:19 +0530
"Naveen N. Rao" wrote:
> If I'm understanding your suggestion right:
> - we now create a new section in each object file: __mcount_loc_weak,
> and capture such relocations using weak symbols there.
Yes, but it would be putting the same information it puts in
Steven Rostedt wrote:
On Fri, 29 Apr 2022 23:09:19 +0530
"Naveen N. Rao" wrote:
If I'm understanding your suggestion right:
- we now create a new section in each object file: __mcount_loc_weak,
and capture such relocations using weak symbols there.
Yes, but it would be putting the same in
On Sat, 30 Apr 2022 01:03:01 +0530
"Naveen N. Rao" wrote:
> > The point of this section is to know which functions in __mcount_loc may
> > have been overridden, as they would be found in the __mcount_loc_weak
> > section. And then we can do something "special" to them.
>
> I'm not sure I follo
On Fri, 29 Apr 2022 16:14:43 +0800
Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When unmapping
On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>> +panic_notifiers_level=
>> +[KNL] Set the panic notifiers execution order.
>> +Format:
>> +We curr
Thanks Marc and Michael for the review/discussion.
On 29/04/2022 15:20, Marc Zyngier wrote:
> [...]
> My expectations would be that, since we're getting here using an IPI,
> interrupts are already masked. So what reenabled them the first place?
>
> Thanks,
>
> M.
>
Marc, I did some inve
Rob Landley writes:
> On 4/27/22 10:27, Thomas Huth wrote:
>> On 26/04/2022 12.26, Rob Landley wrote:
>>> When I cut and paste 80-ish characters of text into the Linux serial
>>> console, it
>>> reads 16 characters and stops. When I hit space, it reads another 16
>>> characters,
>>> and if I ke
On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> Thanks Marc and Michael for the review/discussion.
>
> On 29/04/2022 15:20, Marc Zyngier wrote:
> > [...]
>
> > My expectations would be that, since we're getting here using an IPI,
> > interrupts are already masked. So what
On 29/04/2022 18:45, Russell King (Oracle) wrote:
> [...]
>> Marc, I did some investigation in the code (and tried/failed in the ARM
>> documentation as well heh), but this is still not 100% clear for me.
>>
>> You're saying IPI calls disable IRQs/FIQs by default in the the target
>> CPUs? Where do
On Fri, 29 Apr 2022 22:45:14 +0100,
"Russell King (Oracle)" wrote:
>
> On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> > Thanks Marc and Michael for the review/discussion.
> >
> > On 29/04/2022 15:20, Marc Zyngier wrote:
> > > [...]
> >
> > > My expectations would be tha
On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>>
>> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
>> if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
>> kmsg_dum
On Wed, 27 Apr 2022 23:48:56 +0100,
"Guilherme G. Piccoli" wrote:
>
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs, putting
On Wed, Apr 27, 2022 at 07:49:07PM -0300, Guilherme G. Piccoli wrote:
> Currently many console drivers for s390 rely on panic/reboot notifiers
> to invoke callbacks on these events. The panic() function disables local
> IRQs, secondary CPUs and preemption, so callbacks invoked on panic are
> effect
On 29/04/2022 15:46, Heiko Carstens wrote:
> [...]
>
> Code looks good, and everything still seems to work. I applied this
> internally for the time being, and if it passes testing, I'll schedule
> it for the next merge window.
>
> Thanks!
Perfect Heiko, thanks a bunch for your review and tests!
On 29/04/2022 13:04, Max Filippov wrote:
> [...]
>> arch/xtensa/platforms/iss/setup.c | 4 ++--For xtensa:
>
> For xtensa:
> Acked-by: Max Filippov
>
Perfect, thanks Max!
Cheers,
Guilherme
On 27/04/2022 22:01, Xiaoming Ni wrote:
> [...]
> Duplicate Code.
>
> Is it better to use __func__ and %pS?
>
> pr_info("%s: %pS\n", __func__, n->notifier_call);
>
>
This is a great suggestion Xiaoming, much appreciated!
I feel like reinventing the wheel here - with your idea, code was super
c
Hi Michael, first of all thanks for the great review, much appreciated.
Some comments inline below:
On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> [...]
>> hypervisor I/O completion), so we postpone that to run late. But more
>> relevant: this *same* vmbus unloading happens in the crash_shut
On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
On Fri, 29 Apr 2022 16:14:43 +0800
Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a
On Fri, Apr 29, 2022 at 2:22 AM Palmer Dabbelt wrote:
>
> On Thu, 28 Apr 2022 05:25:19 PDT (-0700), guo...@kernel.org wrote:
> > Hi Palmer,
> >
> > I see you have taken v12 into your riscv-compat branch and added
> > asm/signal32.h. Do you need me help put compat_sigcontext &
> > compat_ucontext &
51 matches
Mail list logo
