Re: [PATCH v2 1/2] powerpc/drmem: accelerate memory_add_physaddr_to_nid() with LMB xarray

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

Re: [PATCH] ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU

onize_rcu() once, then reset each of the buffers. This brings > the time down to about 0.5s. It's gone from somewhere more than 10 minutes (I gave up waiting) to 3 seconds. Nice work! Tested-by: Anton Blanchard Thanks, Anton > Cc: Paul McKenney > Cc: Anton Blanchard > Cc: Ste

CFS bandwidth control hits hard lockup warnings

Hi, We are seeing hard lockup warnings caused by CFS bandwidth control code. The test case below fails almost immediately on a reasonably large (144 thread) POWER9 guest with: watchdog: CPU 80 Hard LOCKUP watchdog: CPU 80 TB:1134131922788, last heartbeat TB:1133207948315 (1804ms ago) Modules

CFS bandwidth control hits hard lockup warnings

Hi, We are seeing hard lockup warnings caused by CFS bandwidth control code. The test case below fails almost immediately on a reasonably large (144 thread) POWER9 guest with: watchdog: CPU 80 Hard LOCKUP watchdog: CPU 80 TB:1134131922788, last heartbeat TB:1133207948315 (1804ms ago) Modules

Re: [PATCH 1/2] ext4: fix warning about stack corruption

> > Unfortunately it doesn't appear to work, at least with ppc64le > > clang: > > > > fs/ext4/mballoc.c:2303:17: error: fields must have a constant size: > > 'variable length array in structure' extension will never be > > supported ext4_grpblk_t counters[blocksize_bits + 2]; > > My fix for

Re: [PATCH 1/2] ext4: fix warning about stack corruption

> > Unfortunately it doesn't appear to work, at least with ppc64le > > clang: > > > > fs/ext4/mballoc.c:2303:17: error: fields must have a constant size: > > 'variable length array in structure' extension will never be > > supported ext4_grpblk_t counters[blocksize_bits + 2]; > > My fix for

Re: [PATCH 1/2] ext4: fix warning about stack corruption

Hi Arnd, > After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for > now"), we get a warning about possible stack overflow from a memcpy > that was not strictly bounded to the size of the local variable: > > inlined from 'ext4_mb_seq_groups_show' at > fs/ext4/mballoc.c:2322:2:

Re: [PATCH 1/2] ext4: fix warning about stack corruption

Hi Arnd, > After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for > now"), we get a warning about possible stack overflow from a memcpy > that was not strictly bounded to the size of the local variable: > > inlined from 'ext4_mb_seq_groups_show' at > fs/ext4/mballoc.c:2322:2:

Re: [PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

ely moved the break even point for this. Acked-by: Anton Blanchard <an...@samba.org> Anton > Signed-off-by: Andrew Jeffery <and...@aj.id.au> > --- > arch/powerpc/lib/copyuser_power7.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/a

Re: [PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

ely 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/arch/pow

[PATCH] [media] ir-spi: Fix issues with lirc API

From: Anton Blanchard <an...@samba.org> The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is incons

[PATCH] [media] ir-spi: Fix issues with lirc API

From: Anton Blanchard The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is inconsistent in how

Re: [PATCH] Enabled pstore write for powerpc

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). > >

Re: [PATCH] Enabled pstore write for powerpc

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). > >

Re: [PATCH] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

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

Re: [PATCH] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

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

Re: 5-level pagetable patches break ppc64le

> > 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 <an...@samba.org> Anton

Re: 5-level pagetable patches break ppc64le

> > 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

5-level pagetable patches break ppc64le

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

5-level pagetable patches break ppc64le

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

[tip:perf/urgent] perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

Commit-ID: 6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Gitweb: http://git.kernel.org/tip/6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Author: Anton Blanchard <an...@samba.org> AuthorDate: Thu, 16 Feb 2017 17:00:50 +1100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 1 Ma

[tip:perf/urgent] perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

Commit-ID: 6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Gitweb: http://git.kernel.org/tip/6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Author: Anton Blanchard AuthorDate: Thu, 16 Feb 2017 17:00:50 +1100 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:26:39 +0100 perf/core: Rename

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

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

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

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

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

From: Anton Blanchard <an...@samba.org> We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently use the plurals. Signed-off-by: Anton Blanchard <an...@samba.org> --- Documentation/trace/kprobetrace.txt

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

From: Anton Blanchard We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently use the plurals. Signed-off-by: Anton Blanchard --- Documentation/trace/kprobetrace.txt | 2 +- Documentation/trace

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

Hi Ingo, > So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and > CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and > CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all > plural. > > I didn't notice the misnomer when merging these bits. Ok,

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

Hi Ingo, > So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and > CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and > CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all > plural. > > I didn't notice the misnomer when merging these bits. Ok,

[PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

From: Anton Blanchard <an...@samba.org> Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT and CONFIG_UPROBE_EVENT. Signed-off-by: Anton Blanchard <an...@samba.org> --- arch/sparc/configs/sparc64_defconfig | 2 +- tools/perf/util/probe-file.c | 8 -

[PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

From: Anton Blanchard Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT and CONFIG_UPROBE_EVENT. Signed-off-by: Anton Blanchard --- arch/sparc/configs/sparc64_defconfig | 2 +- tools/perf/util/probe-file.c | 8 2 files changed, 5 insertions(+), 5

Re: llist code relies on undefined behaviour, upsets llvm/clang

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,

Re: llist code relies on undefined behaviour, upsets llvm/clang

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,

llist code relies on undefined behaviour, upsets llvm/clang

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

llist code relies on undefined behaviour, upsets llvm/clang

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

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

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

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

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

ext4 filesystem corruption with 4.10-rc2 on ppc64le

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

ext4 filesystem corruption with 4.10-rc2 on ppc64le

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

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

//lkml.org/lkml/2016/10/8/189 You can add: Tested-by: Anton Blanchard <an...@samba.org> 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 &

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

//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-by: A

Re: perf TUI fails with "failed to process type: 64"

Hi, I forgot about the set of issues below. Michael had a suggested powerpc fix for 3, but it it would be nice to fix the perf bugs in 1 and 2. Anton -- > Updating to mainline as of last night, I started seeing the following > error when running the perf report TUI: > > 0x46068 [0x8]: failed

Re: perf TUI fails with "failed to process type: 64"

Hi, I forgot about the set of issues below. Michael had a suggested powerpc fix for 3, but it it would be nice to fix the perf bugs in 1 and 2. Anton -- > Updating to mainline as of last night, I started seeing the following > error when running the perf report TUI: > > 0x46068 [0x8]: failed

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

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

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

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

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

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

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

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

[tip:perf/urgent] perf jit: Fix build issue on Ubuntu

Commit-ID: 53613e005496234bb684e5db551fbcededa73999 Gitweb: http://git.kernel.org/tip/53613e005496234bb684e5db551fbcededa73999 Author: Anton Blanchard <an...@samba.org> AuthorDate: Thu, 13 Oct 2016 13:20:43 +1100 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf jit: Fix build issue on Ubuntu

Commit-ID: 53613e005496234bb684e5db551fbcededa73999 Gitweb: http://git.kernel.org/tip/53613e005496234bb684e5db551fbcededa73999 Author: Anton Blanchard AuthorDate: Thu, 13 Oct 2016 13:20:43 +1100 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 17 Oct 2016 11:25:34 -0300 perf jit

[PATCH] perf jit: Fix build issue on Ubuntu

From: Anton Blanchard <an...@samba.org> When building on Ubuntu 16.04, I get the following error: Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop. The problem is that update-java-alternatives has multiple spaces between fields, a

[PATCH] perf jit: Fix build issue on Ubuntu

From: Anton Blanchard When building on Ubuntu 16.04, I get the following error: Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop. The problem is that update-java-alternatives has multiple spaces between fields, and cut treats each space

Re: perf TUI fails with "failed to process type: 64"

Hi Michael, > > 14c00-14c00 g exc_virt_0x4c00_system_call >^ >What's this? The address? If so it's wrong? Offset into the binary I think, there's one 64kB page of ELF gunk at the start. > Seems likely. But I can't see why. > > AFAICS we have never emitted a size for those symbols: >

Re: perf TUI fails with "failed to process type: 64"

Hi Michael, > > 14c00-14c00 g exc_virt_0x4c00_system_call >^ >What's this? The address? If so it's wrong? Offset into the binary I think, there's one 64kB page of ELF gunk at the start. > Seems likely. But I can't see why. > > AFAICS we have never emitted a size for those symbols: >

perf TUI fails with "failed to process type: 64"

Hi, Updating to mainline as of last night, I started seeing the following error when running the perf report TUI: 0x46068 [0x8]: failed to process type: 68 This event is just PERF_RECORD_FINISHED_ROUND: 0x46068 [0x8]: event: 68 . . ... raw event: size 8 bytes . : 44 00 00 00 00 00 08 00

perf TUI fails with "failed to process type: 64"

Hi, Updating to mainline as of last night, I started seeing the following error when running the perf report TUI: 0x46068 [0x8]: failed to process type: 68 This event is just PERF_RECORD_FINISHED_ROUND: 0x46068 [0x8]: event: 68 . . ... raw event: size 8 bytes . : 44 00 00 00 00 00 08 00

Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

Hi Marcelo > This series fixes the memory corruption found by Jan Stancek in > 4.8-rc7. The problem however also affects previous versions of the > driver. If it affects previous versions, please add the lines in the sign off to get it into the stable kernels. Anton

Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

Hi Marcelo > This series fixes the memory corruption found by Jan Stancek in > 4.8-rc7. The problem however also affects previous versions of the > driver. If it affects previous versions, please add the lines in the sign off to get it into the stable kernels. Anton

Re: [PATCH] Work around for enabling CONFIG_CMDLINE on ppc64le

Hi, > But I can't merge that patch. > > Our options are one or both of: > - get GCC fixed and backport the fix to the compilers we care about. > - blacklist the broken compiler versions. > > Is there a GCC bug filed for this? Likely: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709 We

Re: [PATCH] Work around for enabling CONFIG_CMDLINE on ppc64le

Hi, > But I can't merge that patch. > > Our options are one or both of: > - get GCC fixed and backport the fix to the compilers we care about. > - blacklist the broken compiler versions. > > Is there a GCC bug filed for this? Likely: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709 We

[tip:perf/urgent] perf symbols: Fix annotation of objects with debuginfo files

Commit-ID: 50de1a0c54cdbc69a6dbcbc323f53daf95a4050e Gitweb: http://git.kernel.org/tip/50de1a0c54cdbc69a6dbcbc323f53daf95a4050e Author: Anton Blanchard <an...@samba.org> AuthorDate: Sat, 13 Aug 2016 11:55:33 +1000 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf symbols: Fix annotation of objects with debuginfo files

Commit-ID: 50de1a0c54cdbc69a6dbcbc323f53daf95a4050e Gitweb: http://git.kernel.org/tip/50de1a0c54cdbc69a6dbcbc323f53daf95a4050e Author: Anton Blanchard AuthorDate: Sat, 13 Aug 2016 11:55:33 +1000 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 15 Aug 2016 16:49:57 -0300 perf

[PATCH v2] perf symbols: Fix annotation of objects with debuginfo files

From: Anton Blanchard <an...@samba.org> Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate objdump address") started storing the offset of the text section for all DSOs: if (elf_section_by_name(elf, , , ".text", NULL))

[PATCH v2] perf symbols: Fix annotation of objects with debuginfo files

From: Anton Blanchard Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate objdump address") started storing the offset of the text section for all DSOs: if (elf_section_by_name(elf, , , ".text", NULL)) dso->text

[PATCH] perf symbols: Fix annotation of objects with debuginfo files

From: Anton Blanchard <an...@samba.org> Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate objdump address") started storing the offset of the text section for all DSOs: if (elf_section_by_name(elf, , , ".text", NULL))

[PATCH] perf symbols: Fix annotation of objects with debuginfo files

From: Anton Blanchard Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate objdump address") started storing the offset of the text section for all DSOs: if (elf_section_by_name(elf, , , ".text", NULL)) dso->text

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Hi Arnaldo, > Anyway, Anton, does this fix the problem for you? Yes it does, thanks! Anton

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Hi Arnaldo, > Anyway, Anton, does this fix the problem for you? Yes it does, thanks! Anton

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Hi, > Powerpc has Global Entry Point and Local Entry Point for functions. > LEP catches call from both the GEP and the LEP. Symbol table of ELF > contains GEP and Offset from which we can calculate LEP, but debuginfo > does not have LEP info. > > Currently, perf prioritize symbol table over

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

Hi, > Powerpc has Global Entry Point and Local Entry Point for functions. > LEP catches call from both the GEP and the LEP. Symbol table of ELF > contains GEP and Offset from which we can calculate LEP, but debuginfo > does not have LEP info. > > Currently, perf prioritize symbol table over

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

> > I noticed tip started failing in my CI environment which tests on > > QEMU. The failure bisected to commit > > 425209e0abaf2c6e3a90ce4fedb935c10652bf80 > > That's very useful, thanks Anton! > > I have removed this commit from the series for the time being, > refactored the followup

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

> > I noticed tip started failing in my CI environment which tests on > > QEMU. The failure bisected to commit > > 425209e0abaf2c6e3a90ce4fedb935c10652bf80 > > That's very useful, thanks Anton! > > I have removed this commit from the series for the time being, > refactored the followup

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

Hi Anna-Maria, > >> Install the callbacks via the state machine and let the core invoke > >> the callbacks on the already online CPUs. > > > > This is causing an oops on ppc64le QEMU, looks like a NULL > > pointer: > > Did you tested it against tip WIP.hotplug? I noticed tip started failing

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

Hi Anna-Maria, > >> Install the callbacks via the state machine and let the core invoke > >> the callbacks on the already online CPUs. > > > > This is causing an oops on ppc64le QEMU, looks like a NULL > > pointer: > > Did you tested it against tip WIP.hotplug? I noticed tip started failing

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

Hi, > From: Sebastian Andrzej Siewior > > Install the callbacks via the state machine and let the core invoke > the callbacks on the already online CPUs. This is causing an oops on ppc64le QEMU, looks like a NULL pointer: percpu: Embedded 3 pages/cpu @c0001fe0

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

Hi, > From: Sebastian Andrzej Siewior > > Install the callbacks via the state machine and let the core invoke > the callbacks on the already online CPUs. This is causing an oops on ppc64le QEMU, looks like a NULL pointer: percpu: Embedded 3 pages/cpu @c0001fe0 s145816 r0 d50792

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

Hi Thomas, > It really does not matter when we fold the load for the outgoing cpu. > It's almost dead anyway, so there is no harm if we fail to fold the > few microseconds which are required for going fully away. We are seeing the load average shoot up when hot unplugging CPUs (+1 for every CPU

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

Hi Thomas, > It really does not matter when we fold the load for the outgoing cpu. > It's almost dead anyway, so there is no harm if we fail to fold the > few microseconds which are required for going fully away. We are seeing the load average shoot up when hot unplugging CPUs (+1 for every CPU

[PATCH 1/2] exit: Quieten greatest stack depth printk

From: Anton Blanchard <an...@samba.org> Many targets enable CONFIG_DEBUG_STACK_USAGE, and while the information is useful, it isn't worthy of pr_warn(). Reduce it to pr_info(). Signed-off-by: Anton Blanchard <an...@samba.org> --- kernel/exit.c | 2 +- 1 file changed, 1 insertion(+)

[PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

From: Anton Blanchard <an...@samba.org> commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit machines") added a printk without a log level. Quieten it by using pr_info(). Signed-off-by: Anton Blanchard <an...@samba.org> --- mm/workingset.c | 2 +- 1 fil

[PATCH 1/2] exit: Quieten greatest stack depth printk

From: Anton Blanchard Many targets enable CONFIG_DEBUG_STACK_USAGE, and while the information is useful, it isn't worthy of pr_warn(). Reduce it to pr_info(). Signed-off-by: Anton Blanchard --- kernel/exit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/exit.c b

[PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

From: Anton Blanchard commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit machines") added a printk without a log level. Quieten it by using pr_info(). Signed-off-by: Anton Blanchard --- mm/workingset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] powerpc: inline current_stack_pointer()

Hi, > current_stack_pointeur() is a single instruction function. it > It is not worth breaking the execution flow with a bl/blr for a > single instruction Check out bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function not a define") to see why we made it a function. Anton

Re: [PATCH] powerpc: inline current_stack_pointer()

Hi, > current_stack_pointeur() is a single instruction function. it > It is not worth breaking the execution flow with a bl/blr for a > single instruction Check out bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function not a define") to see why we made it a function. Anton

[tip:sched/core] sched/cpuacct: Check for NULL when using task_pt_regs()

Commit-ID: bd92883051a0228cc34996b8e766111ba10c9aac Gitweb: http://git.kernel.org/tip/bd92883051a0228cc34996b8e766111ba10c9aac Author: Anton Blanchard <an...@samba.org> AuthorDate: Wed, 6 Apr 2016 21:59:50 +1000 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[tip:sched/core] sched/cpuacct: Check for NULL when using task_pt_regs()

Commit-ID: bd92883051a0228cc34996b8e766111ba10c9aac Gitweb: http://git.kernel.org/tip/bd92883051a0228cc34996b8e766111ba10c9aac Author: Anton Blanchard AuthorDate: Wed, 6 Apr 2016 21:59:50 +1000 Committer: Ingo Molnar CommitDate: Wed, 13 Apr 2016 13:22:37 +0200 sched/cpuacct: Check

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

task_pt_regs() can return NULL for kernel threads, so add a check. This fixes an oops at boot on ppc64. Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and sys_usage") Signed-off-by: Anton Blanchard <an...@samba.org> Reported-and-Tested-by: Srikar

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

task_pt_regs() can return NULL for kernel threads, so add a check. This fixes an oops at boot on ppc64. Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and sys_usage") Signed-off-by: Anton Blanchard Reported-and-Tested-by: Srikar Dronamraju --- diff --gi

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

atch below does fix the oops for me. Anton -- task_pt_regs() can return NULL for kernel threads, so add a check. This fixes an oops at boot on ppc64. Signed-off-by: Anton Blanchard <an...@samba.org> --- diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index df947e0..41f85c4 100644

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

atch below does fix the oops for me. Anton -- task_pt_regs() can return NULL for kernel threads, so add a check. This fixes an oops at boot on ppc64. Signed-off-by: Anton Blanchard --- diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index df947e0..41f85c4 100644 --- a/kernel/sched/cpu

Re: [tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

Hi, > > > void cpuacct_charge(struct task_struct *tsk, u64 cputime) > > > { > > > struct cpuacct *ca; > > > + int index; > > > + > > > + if (user_mode(task_pt_regs(tsk))) > > > + index = CPUACCT_USAGE_USER; > > > + else > > > + index = CPUACCT_USAGE_SYSTEM; This is oopsing

Re: [tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

Hi, > > > void cpuacct_charge(struct task_struct *tsk, u64 cputime) > > > { > > > struct cpuacct *ca; > > > + int index; > > > + > > > + if (user_mode(task_pt_regs(tsk))) > > > + index = CPUACCT_USAGE_USER; > > > + else > > > + index = CPUACCT_USAGE_SYSTEM; This is oopsing

[tip:perf/urgent] perf jit: genelf makes assumptions about endian

Commit-ID: 9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6 Gitweb: http://git.kernel.org/tip/9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6 Author: Anton Blanchard <an...@samba.org> AuthorDate: Tue, 29 Mar 2016 17:59:44 +1100 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[tip:perf/urgent] perf jit: genelf makes assumptions about endian

Commit-ID: 9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6 Gitweb: http://git.kernel.org/tip/9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6 Author: Anton Blanchard AuthorDate: Tue, 29 Mar 2016 17:59:44 +1100 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 30 Mar 2016 18:12:06 -0300 perf jit

[PATCH] perf jit: genelf makes assumptions about endian

match what gcc emits. We should first look for __powerpc64__, then __powerpc__. Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support") Signed-off-by: Anton Blanchard <an...@samba.org> --- diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h ind

[PATCH] perf jit: genelf makes assumptions about endian

match what gcc emits. We should first look for __powerpc64__, then __powerpc__. Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support") Signed-off-by: Anton Blanchard --- diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h index cd67e64..2fbeb59 100644 -

Re: [PATCH] powerpc: fix dedotify for binutils >= 2.26

> Since binutils 2.26 BFD is doing suffix merging on STRTAB sections. > But dedotify modifies the symbol names in place, which can also modify > unrelated symbols with a name that matches a suffix of a dotted > name. To remove the leading dot of a symbol name we can just > increment the pointer

Re: [PATCH] powerpc: fix dedotify for binutils >= 2.26

> Since binutils 2.26 BFD is doing suffix merging on STRTAB sections. > But dedotify modifies the symbol names in place, which can also modify > unrelated symbols with a name that matches a suffix of a dotted > name. To remove the leading dot of a symbol name we can just > increment the pointer

Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

Hi Scott, > I wonder why it was 64-bit specific in the first place. I think it was part of a series where I added my 64bit assembly checksum routines, and I didn't step back and think that the wrapper code would be useful on 32 bit. Anton -- To unsubscribe from this list: send the line

Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

Hi Scott, > I wonder why it was 64-bit specific in the first place. I think it was part of a series where I added my 64bit assembly checksum routines, and I didn't step back and think that the wrapper code would be useful on 32 bit. Anton -- To unsubscribe from this list: send the line

Re: [PATCH v2] Makefile: Fix detection of clang when cross-compiling

Hi, > > When the host's C compiler is clang, and when attempting to > > cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the > > Makefile would incorrectly detect the use of clang, which > > resulted in clang-specific flags being passed to > > mipsel-linux-gcc. >

Re: [PATCH v2] Makefile: Fix detection of clang when cross-compiling

Hi, When the host's C compiler is clang, and when attempting to cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the Makefile would incorrectly detect the use of clang, which resulted in clang-specific flags being passed to mipsel-linux-gcc.

  1   2   3   4   5   6   >