We observed a kernel oops when running a PPC guest with config NR_CPUS=4
and qemu option "-smp cores=1,threads=8":
[ 30.634781] Unable to handle kernel paging request for data at
address 0xc0014192eb17
[ 30.636173] Faulting instruction address: 0xc003e5cc
[ 30.637069] Oops: Kerne
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Benjamin Herrenschmi
Hello Andrew,
Thank you for your review!
Am Montag, 15 August 2016, 15:27:56 schrieb Andrew Morton:
> On Sat, 13 Aug 2016 00:18:23 -0300 Thiago Jung Bauermann
> wrote:
> > +/**
> > + * kexec_update_segment - update the contents of a kimage segment
> > + * @buffer:New contents of the seg
Le 15/08/2016 à 18:19, Dave Hansen a écrit :
On 08/15/2016 07:35 AM, Holger Brunck wrote:
I tried this but unfortunately the error only occurs while remote debugging.
Locally with gdb everything works fine. BTW we double-checked with a 85xx ppc
target which is also 32-bit and it ends up with t
On 08/16/2016 10:27 AM, christophe leroy wrote:
> If I debug a very small app, it gets stuck quickly after the app has
> stopped: indeed, the console seems ok but as soon as I try to execute
> something simple, like a ps or top, it get stuck. The target still
> responds to pings, but nothing else.
Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh:
> On 16/08/16 00:49, Thiago Jung Bauermann wrote:
> > Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh:
> >> On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote:
> >>> Adapt all callers to the new function prototy
On Mon, 2016-08-15 at 09:19 -0700, Dave Hansen wrote:
>
> Wow, thanks for all the debugging here!
Yup, thanks, that's really odd... I wonder if one of those
structures is accessed beyond it's boundary, either the sigset
or the thread struct, causing corruption of neighbouring fields
in task struc
Hi Michal,
After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
WARNING: 25 bad relocations
c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16
c0cf2578 R_PPC64_ADDR64__crc___arch_hweight32
c0cf2580 R_PPC64_ADDR64
On 17/08/16 04:49, Thiago Jung Bauermann wrote:
> Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh:
>> On 16/08/16 00:49, Thiago Jung Bauermann wrote:
>>> Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh:
On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Hello,
>
> This patch series implements a mechanism which allows the kernel to pass
> on a buffer to the kernel that will be kexec'd. This buffer is passed
> as a segment which is added to the kimage when it is being prepared
> by kexec_file_l
The FPU regs are placed at the top of the stack frame. Currently the
position expected to be passed to the macro. The macros now should be
passed the stack frame size and from there they can calculate where to
put the regs, this makes the use simpler.
Also move them to a header file to be used in
mfmsr() is a fairly expensive call and callers of msr_check_and_set()
may want to make decisions bits in the MSR that it did not change but
may not know the value of.
This patch would avoid a two calls to mfmsr().
Signed-off-by: Cyril Bur
---
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/
If a thread receives a signal while transactional the kernel creates a
second context to show the transactional state of the process. This
test loads some known values and waits for a signal and confirms that
the expected values are in the signal context.
Signed-off-by: Cyril Bur
---
tools/testi
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/gpr_asm.h | 96 +++
1 file changed, 96 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/gpr_asm.h
diff --git a/tools/testing/selftests/powerpc/gpr_asm.h
b/tools/testing/selftests/powerpc/gp
Much of the signal code takes a pt_regs on which it operates. Over
time the signal code has needed to know more about the thread than
what pt_regs can supply, this information is obtained as needed by
using 'current'.
This approach is not strictly incorrect however it does mean that
there is now a
Previous rework of TM code leaves these functions unused
Signed-off-by: Cyril Bur
---
arch/powerpc/include/asm/tm.h | 5 -
arch/powerpc/kernel/fpu.S | 26 --
arch/powerpc/kernel/vector.S | 25 -
3 files changed, 56 deletions(-)
diff --gi
Comment from arch/powerpc/kernel/process.c:967:
If userspace is inside a transaction (whether active or
suspended) and FP/VMX/VSX instructions have ever been enabled
inside that transaction, then we have to keep them enabled
and keep the FP/VMX/VSX state loaded while ever the transaction
conti
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/math/vmx_asm.S | 85 +-
tools/testing/selftests/powerpc/vmx_asm.h | 98 ++
2 files changed, 99 insertions(+), 84 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/vmx_asm.h
If a thread receives a signal while transactional the kernel creates a
second context to show the transactional state of the process. This
test loads some known values and waits for a signal and confirms that
the expected values are in the signal context.
Signed-off-by: Cyril Bur
---
tools/testi
If a thread receives a signal while transactional the kernel creates a
second context to show the transactional state of the process. This
test loads some known values and waits for a signal and confirms that
the expected values are in the signal context.
Signed-off-by: Cyril Bur
---
tools/testi
giveup_all() causes FPU/VMX/VSX facilitities to be disabled in a
threads MSR. If this thread was transactional this should be recorded
as reclaiming/recheckpointing code will need to know.
Fixes: c208505 ("powerpc: create giveup_all()")
Signed-off-by: Cyril Bur
---
arch/powerpc/kernel/process.c
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/Makefile | 1 +
tools/testing/selftests/powerpc/signal/Makefile| 12 +++
tools/testing/selftests/powerpc/signal/signal.S| 50 ++
tools/testing/selftests/powerpc/signal/signal.c| 111
After a thread is reclaimed from its active or suspended transactional
state the checkpointed state exists on CPU, this state (along with the
live/transactional state) has been saved in its entirety by the
reclaiming process.
There exists a sequence of events that would cause the kernel to call
on
If a thread receives a signal while transactional the kernel creates a
second context to show the transactional state of the process. This
test loads some known values and waits for a signal and confirms that
the expected values are in the signal context.
Signed-off-by: Cyril Bur
---
tools/testi
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/harness.c | 9 +++--
tools/testing/selftests/powerpc/utils.h | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/powerpc/harness.c
b/tools/testing/selftests/powerpc/harness.c
index 52f9b
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/tm/tm.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/tools/testing/selftests/powerpc/tm/tm.h
b/tools/testing/selftests/powerpc/tm/tm.h
index 60318ba..2c8da74 100644
--- a/tools/testing/selftests/powe
V3:
In v2 the MSR_{FP,VEC,VSX} bits were left on (if in use) after a
reclaim which meant that signal code did the correct thing.
This also meant that the bits would stay on when a (transactional)
thread was not running and ptrace flush code would notice that tasks
not current have MSR_{FP,VEC,VSX}
Ensure the kernel correctly switches VSX registers correctly. VSX
registers are all volatile, and despite the kernel preserving VSX
across syscalls, it doesn't have to. Test that during interrupts and
timeslices ending the VSX regs remain the same.
Signed-off-by: Cyril Bur
---
tools/testing/self
Make the structures being used for checkpointed state named
consistently with the pt_regs/ckpt_regs.
Signed-off-by: Cyril Bur
---
arch/powerpc/include/asm/processor.h | 8 ++---
arch/powerpc/kernel/asm-offsets.c| 12
arch/powerpc/kernel/fpu.S| 2 +-
arch/powerpc/kernel
There is currently an inconsistency as to how the entire CPU register
state is saved and restored when a thread uses transactional memory
(TM).
Using transactional memory results in the CPU having duplicated
(almost all) of its register state. This duplication results in a set
of registers which c
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/basic_asm.h | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/powerpc/basic_asm.h
b/tools/testing/selftests/powerpc/basic_asm.h
index 3349a07..5131059 100644
--- a/tools/testing/selftests/powerpc/basic_asm
It might be nice to compile selftests against older kernels and
headers but which may not have HWCAP2.
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/utils.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/powerpc/utils.h
b/tools/testing/selftest
On Wed, 2016-08-17 at 13:43 +1000, Cyril Bur wrote:
I obviously didn't proof read that one. This commit message should have
read:
mfmsr() is a fairly expensive call and callers of msr_check_and_set()
may want to make decisions based on the MSR bits that it did not change
but may not know the valu
Hi Cyril,
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.8-rc2 next-20160816]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Cyril-Bur/Consistent-TM-structures/20160817
Hello Dave,
Am Mittwoch, 17 August 2016, 10:52:26 schrieb Dave Young:
> On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > This series applies on top of v5 of the "kexec_file_load implementation
> > for PowerPC" patch series (which applies on top of v4.8-rc1):
> >
> > https://lists.infradea
It's an kernel private macro, it doesn't belong there
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/elf.h | 22 ++
arch/powerpc/include/uapi/asm/elf.h | 23 ---
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch
The variables are defined twice in setup_32.c and setup_64.c, do it
once in setup-common.c instead
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/setup-common.c | 9 +
arch/powerpc/kernel/setup_32.c | 8
arch/powerpc/kernel/setup_64.c | 8
3 files
We don't patch instructions based on the cache lines or block
sizes these days.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/setup_64.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6263e0d..222bbb0 10
The definition is loosely based on sh and alpha, modified to
accomodate larger associativity and cache size for future-proofing.
We currently set all the values to -1 which indicates that the
information isn't available.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/elf.h
It will be used to calculate the associativity
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/cache.h | 2 ++
arch/powerpc/kernel/setup_64.c | 27 +--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b
We have two set of identical struct members for the I and D sides
and mostly identical bunches of code to parse the device-tree to
populate them. Instead make a ppc_cache_info structure with one
copy for I and one for D
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/cache.h
Now that we have all the necessary information available we can
build the L1 cache shape info to be passed down to userspace via
the ELF AUX vectors.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/setup_64.c | 34 ++
1 file changed, 34 insertions(+)
In a number of places we called "cache line size" what is actually
the cache block size, which in the powerpc architecture, means the
effective size to use with cache management instructions (it can
be different from the actual cache line size).
We fix the naming across the board and properly retr
All shipping firmware versions have it wrong in the device-tree
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/setup_64.c | 52 +++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/k
Retrieved from device-tree when available
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/cache.h | 2 ++
arch/powerpc/kernel/setup_64.c | 27 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch
On Fri, Aug 12, 2016 at 09:22:01AM -0600, Alex Williamson wrote:
> On Fri, 12 Aug 2016 15:46:01 +1000
> David Gibson wrote:
>
> > On Wed, Aug 10, 2016 at 10:46:30AM -0600, Alex Williamson wrote:
> > > On Wed, 10 Aug 2016 15:37:17 +1000
> > > Alexey Kardashevskiy wrote:
> > >
> > > > On 09/08/
46 matches
Mail list logo