On 4/28/22 00:49, Guilherme G. Piccoli wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
> spinlock, there's a risk of deadlock.
>
> This
On Wed, Apr 27, 2022 at 07:49:15PM -0300, 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
On 4/27/22 5:49 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 early [but still
On Wed, Apr 27, 2022 at 09:53:38AM +0200, Michael Walle wrote:
> Convert the fsl,layerscape-scfg binding to the new YAML format.
>
> In the device trees, the device node always have a "syscon"
> compatible, which wasn't mentioned in the previous binding.
>
> Also added, compared to the original
On Wed, 27 Apr 2022 09:53:37 +0200, Michael Walle wrote:
> Convert the fsl,ls-extirq binding to the new YAML format.
>
> In contrast to the original binding documentation, there are three
> compatibles which are used in their corresponding device trees which
> have a specific compatible and the
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. Such architectures
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_BUSY
>> + *-3: Invalid sensor. RTAS Parameter Error.
>> + * -9000:
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Acked-by: Geoff Levand
Signed-off-by: Jakub Kicinski
---
CC: kou.ishiz...@toshiba.co.jp
CC: linuxppc-dev@lists.ozlabs.org
---
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
On Tue, Apr 26, 2022 at 11:07:39PM +0530, Mahesh Salgaonkar wrote:
> When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> state as temporarily unavailable until recovery is complete. This also
> triggers an EEH handler in Linux which needs to notify drivers, and perform
>
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 & compat_rt_sigframe into signal32.h? And could we
rename signal32.h to
Below is the serial output at power on. Does anyone have any information at
all? I know the processor is a single 7457 with Marvell/Galileo GT64260A
host bridge. I think the board was made by Motorola or NXP. It has been
difficult to track anything without Wind River support.
-Steve
Steven Rostedt wrote:
On Thu, 28 Apr 2022 13:15:22 +0530
"Naveen N. Rao" wrote:
Indeed, plain old -pg will be a problem. I'm not sure there is a generic
way to address this. I suppose architectures will have to validate the
mcount locations, something like this?
Perhaps another solution is
Steven Rostedt wrote:
On Thu, 28 Apr 2022 13:15:22 +0530
"Naveen N. Rao" wrote:
Indeed, plain old -pg will be a problem. I'm not sure there is a generic
way to address this. I suppose architectures will have to validate the
mcount locations, something like this?
Perhaps another solution is
In the absence of section symbols [1], objtool (today) and recordmcount
(with a subsequent patch) generate __mcount_loc relocation records with
weak symbols as the base. This works fine as long as those weak symbols
are not overridden, but if they are, these can result in duplicate
entries in the
Kernel builds on powerpc are failing with the below error [1]:
CC kernel/kexec_file.o
Cannot find symbol for section 9: .text.unlikely.
kernel/kexec_file.o: failed
Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
symbols") [2], binutils started dropping section
This is v2 of the series posted at:
http://lkml.kernel.org/r/cover.1651047542.git.naveen.n@linux.vnet.ibm.com
For v2, the first patch is slightly modified to skip the loop, rather
than depending on addr == 0 to do so. The second patch is updated to
make this behavior be opt-in by
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
mmapstress03: errno = 12: failed to fiddle with brk at the end
Nicholas Piggin writes:
> Excerpts from Fabiano Rosas's message of April 26, 2022 12:21 am:
>> The hypervisor always sets AMOR to ~0, but let's ensure we're not
>> passing stale values around.
>>
>
> Reviewed-by: Nicholas Piggin
>
> Looks like our L0 doesn't do anything with hvregs.amor ?
It
The session topology test fails in powerpc pSeries platform.
Test logs:
<<>>
Session topology : FAILED!
<<>>
This testcases tests cpu topology by checking the core_id and
socket_id stored in perf_env from perf session. The data from
perf session is compared with the cpu topology information
from
/proc/cpuinfo provides information about type of processor, number
of CPU's etc. Reading /proc/cpuinfo file outputs useful information
by field name like cpu, platform, model (depending on architecture)
and its value separated by colon.
Add new utility function "cpuinfo_field" in "util/header.c"
The session topology test fails in powerpc pSeries platform.
Test logs:
<<>>
Session topology : FAILED!
<<>>
This test uses cpu topology information and in powerpc,
some of the topology info is restricted in environment
like virtualized platform. Hence this test needs to be
skipped in pSeries
On Thu, 28 Apr 2022 13:15:22 +0530
"Naveen N. Rao" wrote:
> Indeed, plain old -pg will be a problem. I'm not sure there is a generic
> way to address this. I suppose architectures will have to validate the
> mcount locations, something like this?
Perhaps another solution is to make the mcount
Em Mon, Apr 25, 2022 at 01:59:03PM -0700, Ian Rogers escreveu:
> On Fri, Apr 15, 2022 at 5:40 PM Namhyung Kim wrote:
> >
> > Hello,
> >
> > This work is a follow-up of Ian's previous one at
> > https://lore.kernel.org/all/20220412154817.2728324-1-irog...@google.com/
> >
> > Fixing up more
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.
cheers
Michael Ellerman (1):
powerpc/64s: Unmerge EX_LR and EX_DAR
Nicholas Piggin
The SLB miss handler is not fully re-entrant, it is able to work because
we ensure that the SLB entries for the kernel text and data segment, as
well as the kernel stack are pinned in the SLB. Accesses to kernel data
outside of those areas has to be carefully managed and can only occur in
certain
From: Nicholas Piggin
This is a minimal stable kernel fix for the problem solved by
4c2de74cc869 ("powerpc/64: Interrupts save PPR on stack rather than
thread_struct").
Upstream kernels between 4.17-4.20 have this bug, so I propose this
patch for 4.19 stable.
Longer description from mpe:
In
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 & compat_rt_sigframe into signal32.h? And could we
rename signal32.h to compat_signal.h to match compat_signal.c?
In the end, thx for taking
Hello,
On Wed, 2022-04-27 at 18:06 +0200, Jakob Koschel wrote:
> To move the list iterator variable into the list_for_each_entry_*()
> macro in the future it should be avoided to use the list iterator
> variable after the loop body.
>
> To *never* use the list iterator variable after the loop it
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The goal of this new panic notifier is to allow its users to
register callbacks to run earlier in the panic path than they
currently do. This aims at informational mechanisms, like dumping
kernel offsets and showing device error data (in case it's
Hi Guilherme,
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic context,
with interrupts and preemption disabled in the running CPU and all other
CPUs disabled. That
Steven Rostedt wrote:
On Wed, 27 Apr 2022 15:01:22 +0530
"Naveen N. Rao" wrote:
If one or both of these weak functions are overridden in future, in the
final vmlinux mcount table, references to these will change over to the
non-weak variant which has its own mcount location entry. As such,
LoPAPR defines guest visible IOMMU with hypercalls to use it -
H_PUT_TCE/etc. Implemented first on POWER7 where hypercalls would trap
in the KVM in the real mode (with MMU off). The problem with the real mode
is some memory is not available and some API usage crashed the host but
enabling MMU was
On 27/04/2022 09:53, Michael Walle wrote:
> Convert the fsl,ls-extirq binding to the new YAML format.
>
> In contrast to the original binding documentation, there are three
> compatibles which are used in their corresponding device trees which
> have a specific compatible and the (already
On 27/04/2022 22:08, Leo Li wrote:
>> Convert the fsl,ls-extirq binding to the new YAML format.
>>
>> In contrast to the original binding documentation, there are three
>> compatibles which are used in their corresponding device trees which have a
>> specific compatible and the (already
On 4/28/22 00:41, Rob Landley wrote:
> 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
>>>
35 matches
Mail list logo