here's no feedback from others I suggest basing your series on top
> of those, and sending them to Corey on the ipmi list to merge.
Looks good, will do.
Thanks,
Anton
> Cheers,
>
> Joel
>
> >
> > Signed-off-by: Anton Blanchard
> > ---
> > .../dev
This adds the Microwatt specific bits, including interrupt support.
Signed-off-by: Anton Blanchard
---
.../devicetree/bindings/ipmi/ibt-bmc.txt | 1 +
drivers/char/ipmi/Kconfig | 8 ++-
drivers/char/ipmi/bt-bmc.c| 69 +++
3 files
The driver is no longer specific to ASPEED, so rename the config option
and remove the dependency on ARCH_ASPEED.
Signed-off-by: Anton Blanchard
---
.../bindings/ipmi/{aspeed,ast2400-ibt-bmc.txt => ibt-bmc.txt} | 2 +-
arch/arm/configs/aspeed_g4_defconfig
While most of the driver is arch agnostic, setting up and handling
interrupts, and enabling the hardware is not. Create bt_bmc_ops to
handle these functions.
Signed-off-by: Anton Blanchard
---
drivers/char/ipmi/bt-bmc.c | 24
1 file changed, 20 insertions(+), 4
Signed-off-by: Anton Blanchard
---
drivers/char/ipmi/bt-bmc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
index f85fafc96ef6..2b0fe1255026 100644
--- a/drivers/char/ipmi/bt-bmc.c
+++ b/drivers/char
Most of the IPMI BT BMC driver is architecture agnostic - it deals with
architected registers and behaviour in the IPMI specification.
Separate out the few ASPEED specific bits into their own functions
so we can use this driver on other architectures.
Signed-off-by: Anton Blanchard
---
drivers
We shouldn't need legacy ptys, and disabling the option improves boot
time by about 0.5 seconds.
Signed-off-by: Anton Blanchard
---
diff --git a/arch/powerpc/configs/microwatt_defconfig
b/arch/powerpc/configs/microwatt_defconfig
index a08b739123da..ebc90aefbc0c 100644
--- a/arch/po
I've forgotten to manual enable NVME when building pseries kernels
for machines with NVME adapters. Since it's a reasonably common
configuration, enable it by default.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/pseries_defconfig | 1 +
1 file changed, 1 insertion(+)
di
Hi Scott,
I'm hitting this issue and Rick just pointed my at your patch. Any
chance we could get it upstream?
Thanks,
Anton
> On PowerPC, memory_add_physaddr_to_nid() uses a linear search to find
> an LMB matching the given address. This scales very poorly when there
> are many LMBs. The poor
4dafc ("powerpc: Add VDSO version of
getcpu")
Signed-off-by: Milton Miller
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/vdso.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e0f4ba45b6cc..8dad44262e
Hi Aneesh,
> > Booting with a 4GB LMB size causes us to panic:
> >
> > qemu-system-ppc64: OS terminated: OS panic:
> > Memory block size not suitable: 0x0
> >
> > Fix pseries_memory_block_size() to handle 64 bit LMBs.
> We need similar changes at more places?
I agree. I wanted to get a m
Booting with a 4GB LMB size causes us to panic:
qemu-system-ppc64: OS terminated: OS panic:
Memory block size not suitable: 0x0
Fix pseries_memory_block_size() to handle 64 bit LMBs.
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
arch/powerpc/platforms/pseries/hotplug
Generic code has a wrapper to implement cputime_to_nsecs() on top of
cputime_to_usecs() but we can easily return the full nanosecond
resolution directly.
Signed-off-by: Anton Blanchard
---
arch/powerpc/include/asm/cputime.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc
eate a worst case situation for mm refcounting by using
the threaded context switch test in will-it-scale set to half the
number of available CPUs (768).
With that workload the patch improves the context switch rate by 118x!
Tested-by: Anton Blanchard
Thanks,
Anton
> diff --git a/arch/
I'm seeing RCU warnings when exiting xmon. xmon resets the NMI watchdog,
but does nothing with the RCU stall or soft lockup watchdogs. Add a
helper function that handles all three.
Signed-off-by: Anton Blanchard
---
arch/powerpc/xmon/xmon.c | 9 -
1 file changed, 8 insertions(
Thanks Nick,
> Signed-off-by: Nicholas Piggin
Tested-by: Anton Blanchard
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 1 +
> arch/powerpc/mm/book3s64/radix_tlb.c | 7 ++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arc
function
descriptor and sys_call_table[] holds pointers to the instruction text.
Fix this by using dereference_kernel_function_descriptor().
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index b9a108411c0d
latencytop adds almost 4kB to each and every task struct and as such
it doesn't deserve to be in our defconfigs.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/g5_defconfig | 1 -
arch/powerpc/configs/gamecube_defconfig | 1 -
arch/powerpc/configs/maple_defconfig| 1 -
signing back to decrementer_clockevent the mult
> and shift values.
Thanks Michael, I missed that completely.
Acked-by: Anton Blanchard
Anton
>
> Fixes: 8b78fdb045de ("powerpc/time: Use
> clockevents_register_device(), fixing an issue with large
> decrementer") Signed-
When analysing sources of OS jitter, I noticed that doorbells cannot be
traced.
Signed-off-by: Anton Blanchard
---
arch/powerpc/include/asm/trace.h | 16
arch/powerpc/kernel/dbell.c | 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/powerpc/include/asm/trace.h
Hi Russell,
> snowpatch builds failed for this patch on all 64-bit configurations
> (ppc64e, ppc64 and ppc64le) with the following:
Thanks! Stupid bug on my part, need more quilt ref. Update to follow.
Anton
> arch/powerpc/kernel/dbell.c:85:9: error: undefined identifier
> 'trace_doorbell_entry
When analysing sources of OS jitter, I noticed that doorbells cannot be
traced.
Signed-off-by: Anton Blanchard
---
arch/powerpc/include/asm/trace.h | 16
arch/powerpc/kernel/dbell.c | 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/powerpc/include/asm/trace.h
s and we end up with 0x7fff even on a large decrementer
capable system.
As suggested by Nick, add a set_state_oneshot_stopped callback
so we program the decrementer with decrementer_max if there are
no future events.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/time.c | 1 +
1
We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.
Signed-off-by: Anton Blanchard
---
arch/powerpc
Hi Nick,
> Thanks for tracking this down. It's a fix for my breakage
>
> a7cba02deced ("powerpc: allow soft-NMI watchdog to cover timer
> interrupts with large decrementers")
>
> Taking another look... what I had expected here is the timer subsystem
> would have stopped the decrementer device af
If CONFIG_PPC_WATCHDOG is enabled, we always cap the decrementer to
0x7fff. As suggested by Nick, add a run time check of the watchdog
cpumask, so if it is disabled we use the large decrementer.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/time.c | 4 +++-
1 file changed, 3
We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.
Signed-off-by: Anton Blanchard
---
arch/powerpc
Hi Michael,
> This breaks GCC 4.6.3 at least, which we still support:
>
> Assembler messages:
> Error: invalid switch -mpower8
> Error: unrecognized option -mpower8
> ../scripts/mod/empty.c:1:0: fatal error: error closing -: Broken
> pipe
Yuck. We have POWER8 instructions in our assembly
From: Anton Blanchard
Static branch hints override dynamic branch prediction on recent
POWER CPUs. We should only use them when we are overwhelmingly
sure of the direction.
Signed-off-by: Anton Blanchard
---
arch/powerpc/lib/mem_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
From: Anton Blanchard
Commit 15a3204d24a3 ("powerpc/64s: Set assembler machine type to POWER4")
passes -mpower4 to the assembler. We have more recent instructions in our
assembly files, but gas permits them. The clang/llvm integrated assembler
is more strict, and we get a build fai
l=-7
>
> Which can be more easily compared to H_NOT_FOUND in hvcall.h
Much nicer.
Acked-by: Anton Blanchard
Anton
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/include/asm/asm-prototypes.h| 3 +--
> arch/powerpc/include/asm/trace.h | 7 +++
>
From: Anton Blanchard
mullw should do a 32 bit signed multiply and create a 64 bit signed
result. It currently truncates the result to 32 bits.
Signed-off-by: Anton Blanchard
---
arch/powerpc/lib/sstep.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib
From: Anton Blanchard
mcrf broke when we changed analyse_instr() to not modify the register
state. The instruction writes to the CR, so we need to store the result
in op->ccval, not op->val.
Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
From: Anton Blanchard
set_cr0() broke when we changed analyse_instr() to not modify the
register state. Instead of looking at regs->gpr[x] which has not
been updated yet, we need to look at op->val.
Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs
Hi Reza,
> I may be misunderstanding this, but what if we did something like x86
> does? When trying to unplug a region smaller than the mapping, they
> fill that part of the pagetable with 0xFD instead of freeing the
> whole thing. Once the whole thing is 0xFD, free it.
>
> See arch/x86/mm/init
From: Anton Blanchard
The thread switch control register (TSCR) is a per core register
that configures how the CPU shares resources between SMT threads.
Exposing it via sysfs allows us to tune it at run time.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/sysfs.c | 8
1 file
Hi,
> There is a similar issue being worked on w.r.t pseries.
>
> https://lkml.kernel.org/r/1502357028-27465-1-git-send-email-bhar...@linux.vnet.ibm.com
>
> The question is should we map these regions ? ie, we need to tell the
> kernel memory region that we would like to hot unplug later so tha
From: Anton Blanchard
Memory hot unplug on PowerNV radix hosts is broken. Our memory block
size is 256MB but since we map the linear region with very large pages,
each pte we tear down maps 1GB.
A hot unplug of one 256MB memory block results in 768MB of memory
getting unintentionally unmapped
, the effect
> is that we put a value in MSR that only has the 0x3f8 bits non-zero,
> meaning that we are switching to 32-bit mode. That leads to a crash
> like this:
Thanks! This fixed the issues I was seeing:
Tested-by: Anton Blanchard
Anton
Hi Nick,
> POWER9 DD2 PMU can stop after a state-loss idle in some conditions.
>
> A solution is to set then clear MMCRA[60] after wake from state-loss
> idle.
Looks good.
Acked-by: Anton Blanchard
Anton
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/ker
set if sdar_mode from event is zero, or we are in continous
> sampling mode in power9 dd1.
>
> But it is preferred to have the sdar_mode value for power9 as
> 0b10 (Update on dcache miss) for better sampling updates instead
> of 0b01 (Update on TLB miss).
Acked-by: Anton Blanchard
Hi,
> > +static notrace int gettime_syscall_fallback(clockid_t clk_id,
> > +struct timespec *tp)
> > +{
> > + register clockid_t id asm("r3") = clk_id;
> > + register struct timespec *t asm("r4") = tp;
> > + register int nr asm("r0") = __NR_clock_getti
Hi Nick,
> POWER9 DD2 can see spurious PMU interrupts after state-loss idle in
> some conditions.
>
> A solution is to save and reload MMCR0 over state-loss idle.
Thanks, looks good.
Tested-by: Anton Blanchard
Anton
> Signed-off-by: Nicholas Piggin
> ---
>
From: Anton Blanchard
The POWER9 branch event is wrong, and we always get a count of zero:
...
0 branches
3844 branch-misses #0.00% of all branches
Replace it with the correct event.
Fixes: d89f473ff6f8 ("powerpc/perf: Fix PM_BRU
From: Anton Blanchard
Similar to POWER8, POWER9 can count run cycles and run instructions
completed on more than one PMU.
Signed-off-by: Anton Blanchard
---
arch/powerpc/perf/power9-events-list.h | 4
arch/powerpc/perf/power9-pmu.c | 2 ++
2 files changed, 6 insertions(+)
diff
Hi Segher,
> On Thu, Jun 15, 2017 at 09:46:38AM +1000, Anton Blanchard wrote:
> > The mcrf emulation code was looking at the CR fields in the reverse
> > order. It also relied on reserved fields being zero which is
> > somewhat fragile, so fix that too.
>
> It maske
From: Anton Blanchard
>From POWER4 onwards, mfocrf() only places the specified CR field into
the destination GPR, and the rest of it is set to 0. The PowerPC AS
from version 3.0 now requires this behaviour.
The emulation code currently puts the entire CR into the destination GPR.
Fix it.
From: Anton Blanchard
The mcrf emulation code was looking at the CR fields in the reverse
order. It also relied on reserved fields being zero which is somewhat
fragile, so fix that too.
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
arch/powerpc/lib/sstep.c | 6 --
1 file
On Sat, 3 Jun 2017 19:42:14 -0300
Breno Leitao wrote:
> Hi Anton,
>
> On Sat, Jun 03, 2017 at 08:04:11AM +1000, Anton Blanchard wrote:
> > Hi Breno,
> >
> > > Currently tsk->thread->load_vec and load_fp are not initialized
> > > during a task c
Hi Breno,
> Currently tsk->thread->load_vec and load_fp are not initialized
> during a task creation, which set garbage to these variables
> (non-zero value).
Nice catch! It seems like we should zero load_tm too though?
Acked-by: Anton Blanchard
Anton
> These variables wil
Hi Michael,
> > ppc64 is the only architecture that turns on
> > VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option
> > is extremely high - a context switch microbenchmark using
> > sched_yield() is almost 20% slower.
>
> Running on what? It should all be nop'ed out unless you'r
From: Anton Blanchard
ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE
by default. The overhead of this option is extremely high - a context
switch microbenchmark using sched_yield() is almost 20% slower.
To get finer grained user/hardirq/softirq statitics, the
From: Anton Blanchard
Allow us to enable IRQ_TIME_ACCOUNTING. Even though we currently
use VIRT_CPU_ACCOUNTING_NATIVE, that option is quite heavy
weight and IRQ_TIME_ACCOUNTING might be better in some cases.
Signed-off-by: Anton Blanchard
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1
s likely moved the break even point for this.
Acked-by: Anton Blanchard
Anton
> Signed-off-by: Andrew Jeffery
> ---
> arch/powerpc/lib/copyuser_power7.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/lib/copyuser_power7.S
> b/arc
Hi Nick,
> An externally triggered system reset (e.g., via QEMU nmi command, or
> pseries reset button) can cause system reset interrupts on all CPUs.
> In case this causes xmon to be entered, it is undesirable for the
> primary (first) CPU into xmon to trigger an NMI IPI to others,
> because this
Hi Ankit,
> After commit c950fd6f201a kernel registers pstore write based on flag
> set. Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG)
> is not set for powerpc architecture. On panic, kernel doesn't write
> message to /fs/pstore/dmesg*(Entry doesn't gets created at all).
>
> Thi
I
see:
HPT:100%
Radix baseline: 248%
Radix patched: 95%
So this patch fixes the large regression we see with radix, and is even
faster than our HPT number now. Nice work!
Acked-by: Anton Blanchard
Anton
> Signed-off-by: Aneesh Kumar K.V
> ---
> Note: not yet tes
Hi Balbir,
> > FTRACE is quite CPU consumming, shouldn't it really be on by
> > default ?
>
> It does some work at boot to NOP out function entry points at _mcount
> locations. Is that what you are referring to? Or the overhead of the
> code in terms of size? Most distro kernels have tracing on
Hi Balbir,
> FYI: The version you applied does not have checks for is_write
Yeah, we decided to do that in a follow up patch. I'm ok if someone
gets to it before me :)
Anton
Hi Oliver,
> From: Rashmica Gupta
>
> Adds support for removing bolted (i.e kernel linear mapping) mappings
> on powernv. This is needed to support memory hot unplug operations
> which are required for the teardown of DAX/PMEM devices.
>
> Cc: Rashmica Gupta
> Cc: A
Hi Ravi,
> If we set a kprobe on a 'stdu' instruction on powerpc64, we see a
> kernel OOPS:
Ouch! We should mark this for stable.
Anton
rmance with these
2 patches.
Acked-by: Anton Blanchard
Anton
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/mm/tlb-radix.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
> index 83d
njamin Herrenschmidt
> Signed-off-by: Aneesh Kumar K.V
Thanks Aneesh.
Acked-by: Anton Blanchard
Anton
> ---
> arch/powerpc/mm/tlb-radix.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
&
Hi Christophe,
> > - if (user_mode(regs))
> > + if (!is_exec && user_mode(regs))
>
> Shouldn't it also check 'is_write' ?
> If it is a store, is_write should be set, shouldn't it ?
Thanks, Ben had the same suggestion. I'll add that further optimisation
in a subsequent patch.
Anton
From: Anton Blanchard
When in the snooze_loop() we want to take up the least amount of
resources. On my version of gcc (6.3), we end up with an extra
branch because it predicts snooze_timeout_en to be false, whereas it
is almost always true.
Use likely() to avoid the branch and be a little
From: Anton Blanchard
The powerpc64 kernel exception handlers have preserved thread priorities
for a long time now, so there is no need to continually set it.
Just set it once on entry and once exit.
Signed-off-by: Anton Blanchard
---
drivers/cpuidle/cpuidle-powernv.c | 2 +-
1 file changed
From: Anton Blanchard
The core of snooze_loop() continually bounces between low and very
low thread priority. Changing thread priorities is an expensive
operation that can negatively impact other threads on a core.
All CPUs that can run PowerNV support very low priority, so we can
avoid the
From: Anton Blanchard
Early on in do_page_fault() we call store_updates_sp(), regardless of
the type of exception. For an instruction miss this doesn't make
sense, because we only use this information to detect if a data miss
is the result of a stack expansion instruction or not.
Worse
Hi Nick,
> > Good idea, I hadn't thought of embedding it all in a feature
> > section.
>
> It may not work currently because you get those ftr_alt_97 relocation
> errors with the "else" parts because relative branches to other code
> need to be direct and I think reachable from both places.
I
From: Anton Blanchard
Early on in do_page_fault() we call store_updates_sp(), regardless of
the type of exception. For an instruction miss this doesn't make
sense, because we only use this information to detect if a data miss
is the result of a stack expansion instruction or not.
Worse
From: Anton Blanchard
The config option for the POWER8 crc32c recently changed from
CONFIG_CRYPT_CRC32C_VPMSUM to CONFIG_CRYPTO_CRC32C_VPMSUM. Update
the configs.
Signed-off-by: Anton Blanchard
From: Anton Blanchard
Most people use perf these days, so save about 31kB by making oprofile
a module.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/powernv_defconfig | 2 +-
arch/powerpc/configs/ppc64_defconfig | 2 +-
arch/powerpc/configs/pseries_defconfig | 2 +-
3 files
From: Anton Blanchard
It turns out cloud-config uses ISO9660 filesystems to inject
configuration data into cloud images. The cloud-config failures when
ISO9660_FS is not enabled are cryptic, and building it in makes
mainline testing easier, so re-enable it.
Signed-off-by: Anton Blanchard
Hi Nick,
> I've got a patch that makes alternate feature patching a bit
> more flexible and not hit relocation limits when using big "else"
> parts. I was thinking of doing something like
>
> _GLOBAL_TOC(copy_page)
> BEGIN_FTR_SECTION_NESTED(50)
> #include "copypage_power9.S"
> FTR_SECTION_ELSE_N
From: Anton Blanchard
Add a POWER9 optimised copy_page() loop. This loop uses the new D form
vector loads and stores, and uses dcbz to pre zero the destination.
A few questions:
- I'm using a nested feature section, but that is going to get unwieldy
at some stage. It would be nice to u
Hi David,
> While not part of this change, the unrolled loops look as though
> they just destroy the cpu cache.
> I'd like be convinced that anything does CRC over long enough buffers
> to make it a gain at all.
btrfs data checksumming is one area.
> With modern (not that modern now) superscalar
et.
>
> Please check if patch by this link helps:
>
> http://lkml.kernel.org/r/20170313052213.11411-1-kirill.shute...@linux.intel.com
It does fix the ppc64le boot hangs, thanks.
Tested-by: Anton Blanchard
Anton
Hi,
My ppc64le boot tests stopped working as of commit c2febafc6773 ("mm:
convert generic code to 5-level paging")
We hang part way during boot, just before bringing up the network. I
haven't had a chance to narrow it down yet.
Anton
> as CRC32c requires.
>
> This probably wasn't caught because btrfs does its own weird
> open-coded initialisation.
>
> Initialise our internal context to ~0 on init.
>
> This makes the self-tests pass, and btrfs continues to work.
Thanks! Not sure how I scr
From: Anton Blanchard
I see a panic in early boot when building with a recent gcc toolchain.
The issue is a divide by zero, which is undefined. Older toolchains
let us get away with it:
int foo(int a) { return a / 0; }
foo:
li 9,0
divw 3,3,9
extsw 3,3
blr
But
Hi Gautham,
> +handle_esl_ec_set:
Unless we want to expose this to things like perf, we might want to
make it a local label (eg .Lxx)
Anton
From: Anton Blanchard
The final paragraph of the help text is reversed - we want to
enable this option by default, and disable it if the toolchain
has a working -mprofile-kernel.
Signed-off-by: Anton Blanchard
---
arch/powerpc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Hi Maddy,
> +EVENT(PM_INST_DISP, 0x200f0)
> +EVENT(PM_INST_DISP_ALT, 0x300f0)
Are you sure these are the right events? 0x200f2, 0x300f2 should be
instruction dispatch I think.
Anton
Hi,
> Anton, I think the behaviour looks good. Actually, it's not very
> relevant to the issue addressed by the patch. I will reply to
> Michael's reply about the reason. There are two nodes in your system
> and the memory is expected to be allocated from node-0. If node-0
> doesn't have enough f
Hi,
> Anton suggested that NUMA distances in powerpc mattered and hurted
> performance without this setting. We need to validate to see if this
> is still true. A simple way to start would be benchmarking
The original issue was that we never reclaimed local clean pagecache.
I just tried all sett
Hi,
gcc trunk has failed to build PowerPC64 kernels for a month or so. The issue
is in oprofile, which is common code but ends up being sucked into
arch/powerpc and therefore subject to the -Werror applied to arch/powerpc:
linux/arch/powerpc/oprofile/../../../drivers/oprofile/oprofile_stats.c: I
Hi,
> We added:
>
> BUILD_BUG_ON(!__builtin_constant_p(feature))
>
> to cpu_has_feature() and mmu_has_feature() in order to catch usage
> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
> LLVM isn't smart enough to resolve this, and it errors out.
>
> I work around it in my
Hi,
We added:
BUILD_BUG_ON(!__builtin_constant_p(feature))
to cpu_has_feature() and mmu_has_feature() in order to catch usage
issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately LLVM
isn't smart enough to resolve this, and it errors out.
I work around it in my clang/LLVM builds
From: Anton Blanchard
IBM bit 31 (for the rest of us - bit 0) is a reserved field in the
instruction definition of mtspr and mfspr. Hardware is encouraged to
(and does) ignore it.
As a result, if userspace executes an mtspr DSCR with the reserved bit
set, we get a DSCR facility unavailable
Hi Peter,
> Last I checked I couldn't build a x86_64 kernel with llvm. So no, not
> something I've ever ran into.
>
> Also, I would argue that this is broken in llvm, the kernel very much
> relies on things like this all over the place. Sure, we're way outside
> of what the C language spec says,
Hi,
I was debugging a hang on a ppc64le kernel built with clang, and it
looks to be undefined behaviour with pointer wrapping in the llist code.
A test case is below. llist_for_each_entry() does container_of() on a
NULL pointer, which wraps our pointer negative, then adds the same
offset back in
From: Anton Blanchard
Commit db9112173b18 ("powerpc: Turn on BPF_JIT in ppc64_defconfig")
only added BPF_JIT to the ppc64 defconfig. Add it to our powernv
and pseries defconfigs too.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/powernv_defconfig | 1 +
arch/power
From: Anton Blanchard
We added support for HAVE_CONTEXT_TRACKING, but placed the option inside
PPC_PSERIES.
This has the undesirable effect that NO_HZ_FULL can be enabled on a
kernel with both powernv and pseries support, but cannot on a kernel
with powernv only support.
Signed-off-by: Anton
Hi Ted,
> Anton or Chandan, could you do me a favor and verify whether or not
> 64k block sizes are working for you on ppcle on ext4 by running
> xfstests? Light duty testing works for me but when I stress ext4 with
> pagesize==blocksize on ppcle64 via xfstests, it blows up. I suspect
> (but am
Hi,
I'm consistently seeing ext4 filesystem corruption using a mainline
kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu
cloud image, boot it in KVM and run:
sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot
And it never makes it back up, dying with rather severe fi
ttps://lkml.org/lkml/2016/10/8/189
You can add:
Tested-by: Anton Blanchard
Also, since this issue makes perf report pretty much useless on
ppc64, can we mark it for stable@, at least to get it into 4.9 where
the ppc64 kernel changes that triggered this appeared?
Anton
> > Reported-
Hi,
A recent binutils commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1a9ccd70f9a75dc6b48d340059f28ef3550c107b
has broken kernel builds:
/home/anton/gcc.install/bin/ld: arch/powerpc/boot/zImage.pseries: Not enough
room for program headers, try linking with -N
/home/anton/
Hi Ben,
> The various calls to establish exception endianness and AIL are
> now done from a single point using already established CPU and FW
> feature bits to decide what to do.
>
> Signed-off-by: Benjamin Herrenschmidt
...
+static void configure_exceptions(void)
+{
+ /* Setup the tramp
Hi,
> kprobe, uprobe, hw-breakpoint and xmon are the only user of
> emulate_step.
>
> Kprobe / uprobe single-steps instruction if they can't emulate it, so
> there is no problem with them. As I mention, hw-breakpoint is broken.
> However I'm not sure about xmon, I need to check that.
I was mostl
Hi Ravi,
> emulate_step() uses a number of underlying kernel functions that were
> initially not enabled for LE. This has been rectified since. So, fix
> emulate_step() for LE for the corresponding instructions.
Thanks. Should this be queued up for stable?
Anton
> Reported-by: Ant
1 - 100 of 1205 matches
Mail list logo