This part was commented from commit 6d492ecc6489
("powerpc/THP: Add code to handle HPTE faults for hugepages")
in about 11 years before.
If there are no plans to enable this part code in the future,
we can remove this dead code and replace with a comment
explaining what the dead code was trying to
On 27/02/2024 09.50, Thomas Huth wrote:
On 26/02/2024 11.11, Nicholas Piggin wrote:
The backtrace handler terminates when it sees a NULL caller address,
but the powerpc stack setup does not keep such a NULL caller frame
at the start of the stack.
This happens to work on pseries because the memo
On 26/02/2024 11.11, Nicholas Piggin wrote:
Add support for backtracing across interrupt stacks, and
add interrupt frame backtrace for unhandled interrupts.
Signed-off-by: Nicholas Piggin
---
lib/powerpc/processor.c | 4 ++-
lib/ppc64/asm/stack.h | 3 +++
lib/ppc64/stack.c | 55 ++
My recent commit e5d00aaac651 ("selftests/powerpc: Check all FPRs in
fpu_preempt") inadvertently broke the fpu_signal test.
It needs to take into account that fpu_preempt now loads 32 FPRs, so
enlarge darray.
Also use the newly added randomise_darray() to properly randomise darray.
Finally the c
On 26/02/2024 11.11, Nicholas Piggin wrote:
Move SPR and MSR defines out of ppc_asm.h and processor.h and into a
new include, asm/reg.h.
Add a define for the PVR SPR and various processor versions, and replace
the open coded numbers in the sprs.c test case.
Signed-off-by: Nicholas Piggin
---
On 26/02/2024 11.11, Nicholas Piggin wrote:
SPRs annotated with SPR_HARNESS can change between consecutive reads
because the test harness code has changed them. Avoid failing the
test in this case.
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 2 +-
1 file changed, 1 insertion(+), 1 de
On 26/02/2024 11.11, Nicholas Piggin wrote:
Storing certain values in MMCR0 can cause PMU interrupts when msleep
enables MSR[EE], and this crashes the test. Freeze the PMU counters
and clear any PMU exception before calling msleep.
Signed-off-by: Nicholas Piggin
---
lib/powerpc/asm/reg.h | 4
On 26/02/2024 11.11, Nicholas Piggin wrote:
Illegal instructions cause 0xe40 (HEAI) interrupts rather
than program interrupts.
Acked-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
lib/powerpc/asm/processor.h | 1 +
lib/powerpc/setup.c | 13 +
powerpc/emulator.c
On 26/02/2024 11.12, Nicholas Piggin wrote:
Add basic testing of various kinds of interrupts, machine check,
page fault, illegal, decrementer, trace, syscall, etc.
This has a known failure on QEMU TCG pseries machines where MSR[ME]
can be incorrectly set to 0.
Two questions out of curiosity:
On 26/02/2024 10.38, Nicholas Piggin wrote:
The infifo fifo that is used to send characters to QEMU console is
only able to receive one character before the cat process exits.
Supporting interactions between test and harness involving multiple
characters requires the fifo to remain open.
This al
On Fri, Mar 01, 2024 at 01:41:22PM +0100, Thomas Huth wrote:
> On 26/02/2024 11.12, Nicholas Piggin wrote:
> > Add basic testing of various kinds of interrupts, machine check,
> > page fault, illegal, decrementer, trace, syscall, etc.
> >
> > This has a known failure on QEMU TCG pseries machines w
On 26/02/2024 10.38, Nicholas Piggin wrote:
Have tests use the new migrate_skip command in skip paths, rather than
calling migrate_once to prevent harness reporting an error.
s390x/migration.c adds a new command that looks like it was missing
previously.
Signed-off-by: Nicholas Piggin
---
ar
On 01/03/2024 14.45, Andrew Jones wrote:
On Fri, Mar 01, 2024 at 01:41:22PM +0100, Thomas Huth wrote:
On 26/02/2024 11.12, Nicholas Piggin wrote:
Add basic testing of various kinds of interrupts, machine check,
page fault, illegal, decrementer, trace, syscall, etc.
This has a known failure on
On 26/02/2024 10.38, Nicholas Piggin wrote:
This matches s390x clock and delay APIs, so common test code can start
using time facilities.
Signed-off-by: Nicholas Piggin
---
lib/powerpc/asm/processor.h | 21 -
lib/powerpc/asm/time.h | 30 ++
On Fri, Mar 01, 2024 at 02:57:04PM +0100, Thomas Huth wrote:
> On 01/03/2024 14.45, Andrew Jones wrote:
> > On Fri, Mar 01, 2024 at 01:41:22PM +0100, Thomas Huth wrote:
> > > On 26/02/2024 11.12, Nicholas Piggin wrote:
> > > > Add basic testing of various kinds of interrupts, machine check,
> > > >
On 26/02/2024 10.38, Nicholas Piggin wrote:
The migration harness is complicated and easy to break so CI will
be helpful.
Signed-off-by: Nicholas Piggin
---
.gitlab-ci.yml | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
Hi Michael,
On Fri, 2024-03-01 at 12:56 +1100, Michael Ellerman wrote:
> OK.
>
> That second iso boots OK for me in qemu. It boots grub and then the
> kernel loads and shows:
>
> Loading ...
> OF stdout device is: /pci@f000/mac-io@c/escc@13000/ch-a@13020
> Preparing to boot Linux versi
Doug!
On Wed, Feb 28 2024 at 14:44, Doug Anderson wrote:
> I won't insist on it, but I continue to worry about memory
> implications with large numbers of CPUs. With a 4-byte int, 8192 max
> CPUs, and 100 IRQs the extra "ref" value takes up over 3MB of memory
> (8192 * 4 bytes * 100).
>
> Technica
On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel
cmdline parameter results in a system hang at boot.
For example, using 'mem=4198400K' will always reproduce this issue.
This patch fixes the problem by aligning any argument to mem= to 16MB
corresponding with the large page
On Fri, Mar 01, 2024 at 03:47:26PM +0100, John Paul Adrian Glaubitz wrote:
> The problem is that the newer image doesn't boot and currently I don't know
> why because installing the exact same kernel later from the package manager
> into an installed system works yields a bootable system with the l
Hi Joel,
Joel Savitz writes:
> On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel
> cmdline parameter results in a system hang at boot.
Can you give us any more details on that? It might be a bug we can fix.
> For example, using 'mem=4198400K' will always reproduce this is
Future changes will need to add a new member to struct
vm_unmapped_area_info. This would cause trouble for any call site that
doesn't initialize the struct. Currently every caller sets each field
manually, so if new fields are added they will be unitialized and the core
code parsing the struct will
On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> I totally understand. If the "uninitialized" warnings were actually
> reliable, I would agree. I look at it this way:
>
> - initializations can be missed either in static initializers or via
> run time initializers. (So the risk of mistake he
On Sat, Mar 02, 2024 at 12:47:08AM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> > I totally understand. If the "uninitialized" warnings were actually
> > reliable, I would agree. I look at it this way:
> >
> > - initializations can be missed either in sta
24 matches
Mail list logo