> Neither of these should ever be changed once set. Make them const and
> fix up the users that try to modify it in-place. In one case
> kmalloc+memcpy is replaced with kstrdup() to avoid modifying the string.
>
> Build tested with defconfigs on ARM, PowerPC, Sparc, MIPS, x86 among
> others.
Gran
Benjamin Herrenschmidt wrote:
> On Thu, 2013-02-21 at 15:52 +1100, Stephen Rothwell wrote:
> > Hi Al,
> >
> > Today's linux-next merge of the signal tree got conflicts in
> > arch/powerpc/kernel/signal_32.c and arch/powerpc/kernel/signal_64.c
> > between commit 2b0a576d15e0 ("powerpc: Add new tr
Thadeu Lima de Souza Cascardo wrote:
> On Fri, Mar 08, 2013 at 03:29:55AM +, Ben Hutchings wrote:
> > On Fri, 2013-03-08 at 13:51 +1100, Michael Neuling wrote:
> > > This patch is breaking the celleb_defconfig on powerpc with:
> > >
> > > arch/power
> do next-* tree support powerpc POWER7 with allmodconfig ?
>
> I met an issue, can we bear it (or I need additional trying) ?
>
>
> Compiling:
> make V=1 EXTRA_CFLAGS=-W ARCH=powerpc allmodconfig
> set cpu type POWER7 in menuconfig.
> set cross-compiler in menuconfig.
> unde
> on x86_64:
>
> drivers/built-in.o: In function `ipoib_changelink':
> ipoib_netlink.c:(.text+0x6a5fc9): undefined reference to `ipoib_set_mode'
> ipoib_netlink.c:(.text+0x6a5fe3): undefined reference to `ipoib_set_mode'
Happens on powerpc too with ppc64e_defconfig compiling modules.
Reverting t
> Please do not add anything to linux-next included branches/series that is
> destined for v3.7 until after v3.6-rc1 is released.
Looks like there is a merge conflict between:
commit 1b074ac867a2bd08a6f12f0feed7d91e06941723
Author: Seth Jennings
Subject: powerpc/crypto: rework Kconfig
and
Seth Jennings wrote:
> On 07/31/2012 12:58 AM, Michael Neuling wrote:
> >> Please do not add anything to linux-next included branches/series that is
> >> destined for v3.7 until after v3.6-rc1 is released.
> >
> > Looks like there is a mer
Michael Neuling wrote:
> Seth Jennings wrote:
>
> > On 07/31/2012 12:58 AM, Michael Neuling wrote:
> > >> Please do not add anything to linux-next included branches/series that is
> > >> destined for v3.7 until after v3.6-rc1 is released.
> > >
Michael Neuling wrote:
> Frederic Weisbecker wrote:
>
> > On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
> > > Hi,
> > >
> > > I've been trying to get hardware breakpoints with perf to work on POWER7
> > > but I'm
Alexander Graf wrote:
>
> On 04.07.2013, at 08:15, Bharat Bhushan wrote:
>
> > From: Bharat Bhushan
> >
> > This patchset moves the debug registers in a structure, which allows
> > kvm to use same structure for debug emulation.
> >
> > Note: Earilier a patchset
> > "https://lists.ozlabs.org
Alexander Graf wrote:
>
> On 09.07.2013, at 06:24, Michael Neuling wrote:
>
> > Alexander Graf wrote:
> >
> >>
> >> On 04.07.2013, at 08:15, Bharat Bhushan wrote:
> >>
> >>> From: Bharat Bhushan
> >>>
> >>&g
Bharat Bhushan wrote:
> This way we can use same data type struct with KVM and
> also help in using other debug related function.
>
> Signed-off-by: Bharat Bhushan
Acked-by: Michael Neuling
> ---
> arch/powerpc/include/asm/processor.h | 38 +
> arc
Bharat Bhushan wrote:
> Signed-off-by: Bharat Bhushan
Acked-by: Michael Neuling
> ---
> arch/powerpc/kernel/process.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> i
city()
> which is only used on POWER7+ and that code excludes this case by
> being limited to SD_SHARE_CPUPOWER which is only ever set on the SMT
> domain which must be the lowest domain and this has singleton groups.
>
> So nothing should be affected by this change.
>
>
> Anyway, I'm attaching my completely mindless test program. It has
> hacky things like "unsigned long count[MAXTHREADS][32]" which are
> purely to just spread out the counts so that they aren't in the same
> cacheline etc.
>
> Also note that the performance numbers it spits out depend a lot on
>
Ben,
> On Mon, 2013-09-30 at 12:29 -0700, Linus Torvalds wrote:
> >
> > But I'm cc'ing the POWER people, because I don't know the POWER8
> > interfaces, and I don't want to necessarily call this "xbegin"/"xend"
> > when I actually wrap it in some helper functions.
>
> The main problem with power
>> Well we don't have to, I think Mikey wasn't totally clear about that
>> "making all registers volatile" business :-) This is just something we
>> need to handle in assembly if we are going to reclaim the suspended
>> transaction.
Yeah, sorry. The slow path with all registers as volatile is onl
The following patch:
acb600d net: remove skb recycling
added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
This is a typo and should be dev_kfree_skb(). This fixes this.
Signed-off-by: Michael Neuling
---
This hit as a compile error in next-20121008 with mpc85xx_defconfig
hout unregistering.
>
> This patch enables hardware breakpoint if the caller is re-registering.
>
> Signed-off-by: Aravinda Prasad
Passes my tests here and I don't think it'll break existing gdb. So FWIW
Acked-by: Michael Neuling
Thanks!
> ---
> arch/powerpc/ker
Oleg Nesterov wrote:
> On 04/16, Michael Neuling wrote:
> >
> > > Benjamin, Paul, arch_dup_task_struct()->flush_ptrace_hw_breakpoint(src)
> > > on powerpc looks "obviously wrong". Don't we need
> > >
> > > - flush_ptrace_
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise.
Tested on POWER and x86.
Signed-off-by: Michael Neuling
Signed-off-by: Nishanth Aravamudan
---
> Wouldn't it be safer to not emit AT_HWCAP2 unless it is define
akpm,
If you're happy with this, is it something you can take in your tree?
Mikey
Michael Neuling wrote:
> We are currently out of free bits in AT_HWCAP. With POWER8, we have
> several hardware features that we need to advertise.
>
> Tested on POWER and x86.
>
>
Michael Ellerman wrote:
> On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> > This patch adds new POWER8 instruction encoding for reading
> > the BHRB buffer entries and also clearing it. Encoding for
> > "clrbhrb" instruction is straight forward.
>
> Which is "clear branch hi
Michael Ellerman wrote:
> On Mon, Apr 22, 2013 at 11:13:43AM +1000, Michael Neuling wrote:
> > Michael Ellerman wrote:
> >
> > > On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> > > > This patch adds new POWER8 instruction encoding
On Thu, May 23, 2013 at 7:07 AM, Andy Lutomirski wrote:
> MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
> it's a hack that steals a bit to indicate to other networking code
> that a compat entry was used. So don't allow it from a non-compat
> syscall.
Dave & Linus
This is cau
Andy Lutomirski wrote:
> I broke them in this commit:
>
> commit 1be374a0518a288147c6a7398792583200a67261
> Author: Andy Lutomirski
> Date: Wed May 22 14:07:44 2013 -0700
>
> net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
>
> This patch adds __sys_sendmsg and __
Grant,
In next-20130617 we are getting the below crash on POWER7. Bisecting,
points to this patch (d39046ec72 in next)
Any clues?
Mikey
Using pSeries machine description
Page sizes from device-tree:
base_shift=12: shift=12, sllp=0x, avpnm=0x, tlbiel=1, penc=0
base_shift=24: shift=
Michael Neuling wrote:
> Grant,
>
> In next-20130617 we are getting the below crash on POWER7. Bisecting,
> points to this patch (d39046ec72 in next)
Also, reverting just d39046ec72 fixes the crash in next-20130617.
Mikey
>
> Any clues?
>
> Mikey
>
>
>
Grant Likely wrote:
> On Tue, 18 Jun 2013 10:05:31 +0100, Grant Likely
> wrote:
> > On Tue, Jun 18, 2013 at 2:25 AM, Michael Neuling wrote:
> > > Michael Neuling wrote:
> > >
> > >> Grant,
> > >>
> > >> In next-20130617 we a
Sukadev Bhattiprolu wrote:
> From 9f1a8a16e0ef36447e343d1cd4797c2b6a81225f Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Fri, 7 Jun 2013 13:26:31 -0700
> Subject: [PATCH 2/2] perf: Add support for the mem_xlvl field.
>
> A follow-on patch to adding perf_mem_data_src support for P
Suka,
One of these two patches breaks pmac32_defconfig and I suspect all other
32 bit configs (against mainline)
arch/powerpc/perf/core-book3s.c: In function 'record_and_restart':
arch/powerpc/perf/core-book3s.c:1632:4: error: passing argument 1 of
'ppmu->get_mem_data_src' from incompatible poin
Aruna Balakrishnaiah wrote:
> Currently the kernel provides the contents of p-series NVRAM only as a
> simple stream of bytes via /dev/nvram, which must be interpreted in user
> space by the nvram command in the powerpc-utils package. This patch set
> exploits the pstore subsystem to expose each p
Aruna Balakrishnaiah wrote:
> Hi Michael,
>
> On Wednesday 19 June 2013 11:45 AM, Michael Neuling wrote:
> > Aruna Balakrishnaiah wrote:
> >> Currently the kernel provides the contents of p-series NVRAM only as a
> >> simple stream of bytes via /dev/nvram,
> Enable PSTORE in pseries_defconfig
Please add a "why" to your changelogs eg. "Now we have pstore support for
nvram on pseries, enable it in the default config"
"Why" you are changing something is more important than "what", since
you can always determine "what" is being changed, by looking at t
Aruna Balakrishnaiah wrote:
> Since now we have pstore support for nvram in pseries, enable it
> in the default config. With this config option enabled, pstore
> infra-structure will be used to read/write the messages from/to nvram.
>
> Signed-off-by: Aruna Balakrishnaiah
Ac
Guenter Roeck wrote:
> On Fri, Jun 07, 2013 at 12:58:16PM -0700, Greg KH wrote:
> > I'm announcing the release of the 3.9.5 kernel.
> >
> > All users of the 3.9 kernel series must upgrade.
> >
> > The updated 3.9.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/
completions.
This is great, thanks a lot.
If you want this to be picked up by the maintainer, you'll need to add
your signed-off-by.
The signed-off-by is to indicate that your happy for it to be included
and that you're legally allowed to do so. See
http://gerrit.googlecode.com/svn/docu
; but still not enough (still content overflow bytes)
> >
> > additional trying:
> > after del CONFIG_VSX and CONFIG_PPC_970_NAP in allmodconfig,
> > (will reduce dozens bytes in the region .0x5500 -- .0x7000)
> > it can pass compilin
Chen Gang wrote:
> On 2013年03月22日 06:54, Michael Neuling wrote:
> > This is great, thanks a lot.
> >
> > If you want this to be picked up by the maintainer, you'll need to add
> > your signed-off-by.
> >
> > The signed-off-by is to indicate that y
Stuart Yoder wrote:
> From: Stuart Yoder
>
> For 32-bit, CONFIG_EPAPR_PARAVIRT pulls in both epapr_paravirt.c
> and epapr_hcalls.c which contains the 32-bit paravirt idle loop.
>
> For 64-bit, the paravirt idle loop is in idle_book3e.S and that
> source file is included only if CONFIG_PPC_BOOK
ranction" they can just plug it in. Otherwise they will nop it,
> > as it's only hints anyways.
> >
> > The only things used outside x86 code is _xtest()/_xabort(), can
> > remove the rest from linux/*. Without transactions this is all nops.
> > The primary
> From: Andi Kleen
>
> Add generic noop macros (act like transaction aborted) for RTM.
> The main use case is an occasional _xtest() added to generic
> code, without needing ifdefs. On x86+RTM this will use
> real TSX instructions.
>
> Signed-off-by: Andi Kleen
> ---
> include/linux/rtm.h |
> From: Andi Kleen
>
> Writing _xbegin which is like setjmp in a if is very natural.
> Stop checkpatch's whining about this.
This patch should go in before the RTM tester.
>
> Cc: a...@canonical.com
> Signed-off-by: Andi Kleen
> ---
> scripts/checkpatch.pl |5 -
> 1 files changed,
> From: Andi Kleen
>
> This adds the basic RTM (Restricted Transactional Memory)
> intrinsics for TSX, implemented with alternative() so that they can be
> transparently used without checking CPUID first.
>
> When the CPU does not support TSX we just always jump to the abort handler.
>
> These
Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 25 Mar 2013 09:31:31 +0800 Chen Gang wrote:
> >
> > The FWNMI region is fixed at 0x7000 and the vector are now overflowing
> > that with allmodconfig. Fix that by moving slb_miss_realmode code out
> > of that region as it doesn't need to be th
Andi Kleen wrote:
> > RTM == restricted transactional memory. I don't understand why it's
> > "restricted" and why any other architecture else would call it that and
>
> It's restricted as in there is no guarantee that a transaction ever succeeds
> and always needs a fallback path. My understan
Andi Kleen wrote:
> > FYI the TM spec can be downloaded here:
> > https://www.power.org/documentation/power-isa-transactional-memory/
> >
> > You're example code looks like this:
>
> I don't think portable code will use this directly. Note it's in arch/x86/
>
> Generally portable code should
ny of the icp VCPU
pointers. This manifests itself later in boot when trying to raise an
IRQ resulting in a null pointer deference/segv.
This moves xics_init() to use dev_base_init() to ensure it happens after
kvm_cpu_init().
Signed-off-by: Michael Neuling
diff --git a/tools/kvm/powerpc/xics.c b/
Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra
> > wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen
> > > Cc: eran...@google.com
> > > Signe
Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra
> > wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen
> > > Cc: eran...@google.com
> > > Signe
() never fails and it is used in multiple places so it has not
> been changed by this patch.
>
> Signed-off-by: Alexey Kardashevskiy
FWIW:
Acked-by: Michael Neuling
> ---
> arch/powerpc/include/asm/ptrace.h |3 ++-
> arch/powerpc/kernel/ptrace.c | 29 +
Anshuman Khandual wrote:
> Fixing some conditions during BHRB entry processing.
I think we can simplify this a lot more... something like the below.
Also, this marks the "to" address as all 1s, which is better poison
value since it's possible to branch to/from 0x0.
diff --git a/arch/powerpc/pe
Anshuman Khandual wrote:
> On 05/06/2013 04:41 PM, Michael Neuling wrote:
> > Anshuman Khandual wrote:
> >
> >> Fixing some conditions during BHRB entry processing.
> >
> > I think we can simplify this a lot more... something like the below.
> >
&g
Peter & Stephane,
We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
struct perf_branch_entry.
Sometimes on POWER8 we may not be able to fill out the "to" address. We
initially thought of just making this 0, but it's feasible that this
could be a valid address to branch to.
T
Peter Zijlstra wrote:
> On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> > Peter & Stephane,
> >
> > We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
> > struct perf_branch_entry.
> >
> > Sometimes on POWER8 we m
Stephane Eranian wrote:
> On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra wrote:
> > On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> >> Peter & Stephane,
> >>
> >> We are plumbing the POWER8 Branch History Rolling Buffer (
On Fri, May 10, 2013 at 8:43 PM, Peter Zijlstra wrote:
> On Thu, May 09, 2013 at 08:39:15AM +1000, Michael Neuling wrote:
>> > Just because I'm curious.. however does that happen? Surely the CPU
>> > knows where next to fetch instructions?
>>
>> For computed
Mike Qiu wrote:
> 于 2013/4/24 16:31, Michael Ellerman 写道:
> > On Wed, Apr 24, 2013 at 04:22:53PM +0800, Mike Qiu wrote:
> >> Hi all
> >>
> >> I get an error message when I compile the source code in Power7 platform
> >> use the newest upstream kernel.
> > Hi Mike,
> >
> > It depends on what your
Chen Gang wrote:
>
> When CONFIG_KVM_BOOK3S_64_PR is enabled,
> MASKABLE_EXCEPTION_PSERIES(0x900 ...) will includes __KVMTEST, it will
> exceed 0x980 which STD_EXCEPTION_HV(0x980 ...) will use, it will cause
> compiling issue.
>
> The related errors:
> arch/powerpc/kernel/exceptions-64s.S: Asse
Chen Gang wrote:
>
> When CONFIG_KVM_BOOK3S_64_PR is enabled,
> MASKABLE_EXCEPTION_PSERIES(0x900 ...) will includes __KVMTEST, it will
> exceed 0x980 which STD_EXCEPTION_HV(0x980 ...) will use, it will cause
> compiling issue.
>
> The related errors:
> arch/powerpc/kernel/exceptions-64s.S: Asse
Anshuman,
IIRC there are new bits in the FSCR and HFSCR you need to enable for the
PMU and BRHB. Can you please check these are enabled?
Mikey
Anshuman Khandual wrote:
> Branch History Rolling Buffer (BHRB) is a new PMU feaure in
> IBM
> POWER8 processor which records the bran
on it doesn't crash this case (ie. mainline passes).
As for the rest of your series, it passes my tests on powerpc, so I'm
good with it.
Acked-by: Michael Neuling
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra
> > wrote:
> > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> > >> Peter,
> > >>
&
Stephane Eranian wrote:
> On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra wrote:
> > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
> >> Peter Zijlstra wrote:
> >
> >> > Wouldn't it be mostly conditional branches that are the primar
Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra
> > wrote:
> > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> > >> Peter,
> > >>
&
Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 11:52:38AM +0530, Anshuman Khandual wrote:
> > Enables conditional branch filter support for POWER8
> > utilizing MMCRA register based filter and also invalidates
> > a BHRB branch filter combination involving conditional
> > branches.
> >
> > Sign
Anshuman Khandual wrote:
> On 05/22/2013 02:29 PM, Anshuman Khandual wrote:
> >>
> >> Your description from patch 0 should be here.
> > Does it sound better ?
> >
> >>
> >>> - if ((br_privilege != 7) && (br_privilege != 0))
> >>> - return -1;
> >>> +
> >>> + if (br_privilege)
> >>> +
> bisect tells me that since your commit
> 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
> "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint
> registers",
> compiling linux fails with :
>
> cc1: warnings being treated as errors
> arch/powerpc/kernel/ptrace.c: In function 'arch
Philippe De Muyter wrote:
> On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > bisect tells me that since your commit
> > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
> > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint
Philippe De Muyter wrote:
> Hello Mikey,
>
> On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> > Philippe De Muyter wrote:
> >
> > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > >
Michael Neuling wrote:
> Philippe De Muyter wrote:
>
> > Hello Mikey,
> >
> > On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> > > Philippe De Muyter wrote:
> > >
> > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, M
This patch is breaking the celleb_defconfig on powerpc with:
arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
arch/powerpc/kernel/of_platform.c:95:2: error: implicit declaration of
function 'eeh_add_sysfs_files' [-Werror=implicit-function-declaration]
Mikey
On Mon, Mar 4, 2013
Ben Hutchings wrote:
> On Fri, 2013-03-08 at 13:51 +1100, Michael Neuling wrote:
> > This patch is breaking the celleb_defconfig on powerpc with:
> >
> > arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
> > arch/powerpc/kernel/of_platform.c
module
>
> still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it
> is now a bool in the Kconfig. This patch repairs the break.
>
> Reported-by: Michael Neuling
> Signed-off-by: Seth Jennings
> ---
> This patch is based on Linus master which already contains
&g
module
>
> still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it
> is now a bool in the Kconfig. This patch repairs the break.
>
> Reported-by: Michael Neuling
> Signed-off-by: Seth Jennings
Works, thanks.
Tested-by: Michael Neuling
> ---
> This patch is ba
Hi,
I've been trying to get hardware breakpoints with perf to work on POWER7
but I'm getting the following:
% perf record -e mem:0x1000 true
Error: sys_perf_event_open() syscall returned with 28 (No space left on
device). /bin/dmesg may provide additional information.
Fatal: No
Peter,
> > On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
> > despite there being no breakpoint on this CPU. This is because the call
> > the task_bp_pinned, checks all CPUs, rather than just the current CPU.
> > POWER7 only has one hardware breakpoint per CPU (ie. HBP_N
> > > > On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
> > > > despite there being no breakpoint on this CPU. This is because the call
> > > > the task_bp_pinned, checks all CPUs, rather than just the current CPU.
> > > > POWER7 only has one hardware breakpoint per CPU (i
Frederic Weisbecker wrote:
> On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
> > Hi,
> >
> > I've been trying to get hardware breakpoints with perf to work on POWER7
> > but I'm getting the following:
> >
> > % perf
Greg Kroah-Hartman wrote:
> On Sun, Jul 08, 2012 at 07:55:55PM +0200, Kay Sievers wrote:
> > On Sat, 2012-07-07 at 07:04 +1000, Michael Neuling wrote:
> > > Whole kmsg below.
> >
> > I guess I have an idea now what's going on.
> >
> > > 4,47,0;
Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> arch/powerpc/kernel/kgdb.c: In function 'kgdb_arch_exit':
> arch/powerpc/kernel/kgdb.c:492:2: error: '__debugger_breakx_match' undeclared
> (first use in
Kay Sievers wrote:
> On Fri, Jul 6, 2012 at 12:46 PM, Kay Sievers wrote:
> > On Fri, Jul 6, 2012 at 5:47 AM, Michael Neuling wrote:
> >
> >>> 4,89,24561;NIP: c0048164 LR: c0048160 CTR:
> >>>
> >>> 4,90,2
In message <[EMAIL PROTECTED]> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> > a) if there are a finite number of handles and we can predict their
> > values, just delete them all in the kdump kernel before the driver
> > loads.
>
>
> > Fix a couple of minor issues with the getdelays.c example code.
>
> What issues?
-l option (loop) doesn't work and it seg faults in print_delayacct.
Mikey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
Fix a couple of minor issues with the getdelays.c example code.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Documentation/accounting/getdelays.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
Index: linux-2.6-ozlabs/Documentation/acco
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> > Fix a couple of minor issues with the getdelays.c example code.
> >
> > Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> > ---
> > Documentation/accounting/getdelays.c | 21
> Interesting, we never used -l that way. We used -l to get data for all
> exiting tasks
>
> ./getdelays -d -l
>
> For the usage you've mentioned, I'd use
>
> while :
> do
> sleep 2
> ./getdelays -p 1 -d
> done
>
> I guess your changes change getdelays and since there are other ways
b663a79c191508f27cd885224b592a878c0ba0f6 incorrectly removed a comma
from a printf statement. This causes corruption in the output printing
or a seg fault.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Documentation/accounting/getdelays.c |2 +-
1 file changed, 1 insertion
This adds two items to the taststats struct to account for user and
system time based on scaling the CPU frequency and instruction issue
rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can use to account for time using this mechanism.
Signed-off-by: Michael Neuling
2 868.66 -0.8533
Process fork+/bin/sh -c: 28302876.5 1.64312958 4.52296
File /var/tmp/XXX write bw: 1193497 1195536 0.1708118657 -0.5799
Pagefaults on /var/tmp/XXX: 3.1272 3.2117 2.70203.2521 3.99398
Also, kernel compile times show no difference with this p
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> > This adds POWERPC specific hooks for scaled time accounting.
> >
> > POWER6 includes a SPURR register. The SPURR is based off the PURR
> > register but is scaled based on CPU frequency a
In message <[EMAIL PROTECTED]> you wrote:
> Hi, Michael,
>
> Thanks for doing this, this is really useful.
>
> Michael Neuling wrote:
> > This adds two items to the taststats struct to account for user and
> > system time based on scaling the CPU frequenc
This adds items to the taststats struct to account for user and system
time based on scaling the CPU frequency and instruction issue rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can use to account for time using this mechanism.
Signed-off-by: Michael Neuling
> Hi,
>
> My machine reboots automatically after a few seconds of booting 2.6.23-rc2-mm
2.
> I've tried several ways to debug the problem, but I've had no success.
> I am not sure if this problem has been reported already, a few simple searche
s
> did not indicate that the problem had been reporte
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> >> I'd also request for you to add a cpu_scaled_run_real_total for use
> >> by delay accounting. cpu_scaled_run_real_total should be similar in
> >> functionality to cpu_run_re
the last SPURR/PURR ratio
calculated. The generic and s390 (only other arch to implement
asm/cputime.h) versions are both NOPs.
Also moves the SPURR and PURR snapshots closer.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c| 14 +++---
inclu
> Michael Ellerman <[EMAIL PROTECTED]> wrote on 02.11.2007 07:30:08:
>
> > On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > > Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
> > If that's really the way it works then eHEA is more or less broken for
> > kdump I'm af
> > +#ifndef CONFIG_VIRT_CPU_ACCOUNTING
> > +void account_process_tick(int user_tick)
> > +{
> > + if (user_tick) {
> > + account_user_time(p, jiffies_to_cputime(1));
> > + account_user_time_scaled(p, jiffies_to_cputime(1));
> > + } else {
> > +
> To support ehea driver reloading in a kdump kernel the driver has to
> perform firmware handle deregistrations when the original kernel
> crashes. As there's currently no notifier chain for machine crashes
> this patch enables kdump support in the ehea driver by bending the
> ppc_md.machine_crash
In message <[EMAIL PROTECTED]> you wrote:
> On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
> > On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > > > >Is there a kexec-tools patch too? How does second kernel know about
> > > > >
1 - 100 of 293 matches
Mail list logo
