On Fri, Jul 26, 2013 at 11:19:13AM +1000, Anton Blanchard wrote:
>
> Hi Neil,
>
> > Sorry I'm a bit late to the thread, I've ben swamped. Has someone
> > tested this with kexec/kdump? Thats why the origional patch was
> > created, because when kexec loads the kernel at a different physical
> >
On Fri, Jul 26, 2013 at 11:19:13AM +1000, Anton Blanchard wrote:
Hi Neil,
Sorry I'm a bit late to the thread, I've ben swamped. Has someone
tested this with kexec/kdump? Thats why the origional patch was
created, because when kexec loads the kernel at a different physical
address,
Hi Neil,
> Sorry I'm a bit late to the thread, I've ben swamped. Has someone
> tested this with kexec/kdump? Thats why the origional patch was
> created, because when kexec loads the kernel at a different physical
> address, the relocations messed with the module crc's, and modules
> couldn't
On Thu, Jul 25, 2013 at 09:14:25AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > > Apart from the annoying colors, is there anything specific I should
> > > be looking for? Some sort of error message, or output that actually
> > > makes
On Thu, Jul 25, 2013 at 09:14:25AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
Apart from the annoying colors, is there anything specific I should
be looking for? Some sort of error message, or output that actually
makes sense?
Hi Neil,
Sorry I'm a bit late to the thread, I've ben swamped. Has someone
tested this with kexec/kdump? Thats why the origional patch was
created, because when kexec loads the kernel at a different physical
address, the relocations messed with the module crc's, and modules
couldn't load
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > Apart from the annoying colors, is there anything specific I should
> > be looking for? Some sort of error message, or output that actually
> > makes sense?
>
> Thanks for testing! Ben, I think the patch is good to go.
Sent it
Hi Scott,
> I'm not really sure what it's supposed to look like when "perf
> annotate" works. It spits a bunch of unreadable[1]
> dark-blue-on-black assembly code at me, all with "0.00 :" in the left
> column.
>
> Oh, wait -- some lines have "100.00 : " on the left, in
>
On 07/23/2013 08:30:32 AM, Michael Ellerman wrote:
On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
> On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
> >
> >Hi Scott,
> >
> >> What specifically should I do to test it?
> >
> >Could you double check perf annotate works? I'm 99% sure
Hi Scott,
I'm not really sure what it's supposed to look like when perf
annotate works. It spits a bunch of unreadable[1]
dark-blue-on-black assembly code at me, all with 0.00 : in the left
column.
Oh, wait -- some lines have 100.00 : on the left, in
even-more-unreadable
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
Apart from the annoying colors, is there anything specific I should
be looking for? Some sort of error message, or output that actually
makes sense?
Thanks for testing! Ben, I think the patch is good to go.
Sent it yesterday to
On 07/23/2013 08:30:32 AM, Michael Ellerman wrote:
On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
Hi Scott,
What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will
but
On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
> On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
> >
> >Hi Scott,
> >
> >> What specifically should I do to test it?
> >
> >Could you double check perf annotate works? I'm 99% sure it will but
> >that is what was failing on ppc64.
>
>
On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
Hi Scott,
What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will but
that is what was failing on ppc64.
I'm not really
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
Hi Scott,
> What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will but
that is what was failing on ppc64.
I'm not really sure what it's supposed to look like when "perf
annotate" works.
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
Hi Scott,
What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will but
that is what was failing on ppc64.
I'm not really sure what it's supposed to look like when perf
annotate works. It
Hi Scott,
> What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will but
that is what was failing on ppc64.
Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Hi Scott,
What specifically should I do to test it?
Could you double check perf annotate works? I'm 99% sure it will but
that is what was failing on ppc64.
Anton
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 07/16/2013 07:04:05 PM, Benjamin Herrenschmidt wrote:
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote:
> On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> > > Module CRCs are implemented as absolute symbols that get
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote:
> On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> > > Module CRCs are implemented as absolute symbols that get resolved by
> > > a linker script. We build an intermediate
On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms
On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote:
On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that
On 07/16/2013 07:04:05 PM, Benjamin Herrenschmidt wrote:
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote:
On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
Module CRCs are implemented as absolute symbols that get
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms parses this .o, calculates
> the CRCs and writes a linker
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script
Anton Blanchard writes:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms parses this .o, calculates
> the CRCs and writes a linker script that "resolves" the symbols
Anton Blanchard an...@samba.org writes:
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that resolves the
28 matches
Mail list logo
