M. Mohan Kumar | 3 Aug 07:49 2009
Picon

Re: [PATCH] Do not inline putprops function

On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote:
> On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > > 
> > Well it definately looks like removing that variable had some code changes.
> > It'll take some time to match it up to source, but Most interesting I think is
> > the variance in putprops around address f34.  Looks like its doing some string
> > maniuplation in a reversed order, using a huge offset.  Might be worthwhile to
> > check to see if theres any string overruns in this code.
> 
> Yeah I still suspect it's just a bug in the code that's being exposed
> now.
> 
Hi,

The same code works with gcc-3.4.

> Mohan, can you try running it under valgrind?

Still I am not able to use valgrind to debug kexec-tools

Regards,
M. Mohan Kumar.
M. Mohan Kumar | 5 Aug 18:49 2009
Picon

Re: [PATCH] Do not inline putprops function

Hi,

When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.

When the line
	static unsigned dtstruct[TREEWORDS], *dt;
changed to 
	static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;

kexec-tool works.

Regards,
M. Mohan Kumar

On Mon, Aug 03, 2009 at 11:19:19AM +0530, M. Mohan Kumar wrote:
> On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote:
> > On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> > > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > > > 
> > > Well it definately looks like removing that variable had some code changes.
> > > It'll take some time to match it up to source, but Most interesting I think is
> > > the variance in putprops around address f34.  Looks like its doing some string
> > > maniuplation in a reversed order, using a huge offset.  Might be worthwhile to
> > > check to see if theres any string overruns in this code.
> > 
> > Yeah I still suspect it's just a bug in the code that's being exposed
> > now.
> > 
> Hi,
> 
(Continue reading)

Michael Ellerman | 6 Aug 16:24 2009
Picon

Re: [PATCH] Do not inline putprops function

On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote:
> Hi,
> 
> When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.
> 
> When the line
> 	static unsigned dtstruct[TREEWORDS], *dt;
> changed to 
> 	static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
> 
> kexec-tool works.

Hmm, odd.

Can you check how it's aligned without your change? ie. in the original
binary, is it 4 byte aligned?

When you make the change, is the only thing that changes in the binary
the alignedness of dtstruct, or does it cause other things to move
around?

I don't think an unaligned dt blob should have any effect on the kernel,
ie. it should copy it in fine, but I'd have to look at the code.

cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
(Continue reading)

M. Mohan Kumar | 7 Aug 16:35 2009
Picon

Re: [PATCH] Do not inline putprops function

Hi,

After enabling EARLY_DEBUG (and DEBUG in some of the files in
arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
byte alignment: 

# ./kexec -e
Starting new kernel
console [udbg0] enabled
 -> early_setup(), dt_ptr: 0x7723000
 -> early_init_devtree(c000000007723000)
Invalid tag 5 scanning flattened device tree !
search "chosen", depth: 0, uname:
Invalid tag 5 scanning flattened device tree !
dt_root_size_cells = 2
dt_root_addr_cells = 2
Invalid tag 5 scanning flattened device tree !
reserving: 128c000 -> 5ec1f7
reserving: 7734000 -> 8cc000
reserving: 7723000 -> f698
Phys. mem: 0
-> move_device_tree
<- move_device_tree
Scanning CPUs ...
Invalid tag 5 scanning flattened device tree !
 <- early_init_devtree()
Probing machine type ...
  pSeries ...
No suitable machine found !

(Continue reading)

M. Mohan Kumar | 7 Aug 16:54 2009
Picon

Re: [PATCH] Do not inline putprops function

On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote:
> Hi,
> 
> After enabling EARLY_DEBUG (and DEBUG in some of the files in
> arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
> byte alignment: 
> 
> # ./kexec -e
> Starting new kernel
> console [udbg0] enabled
>  -> early_setup(), dt_ptr: 0x7723000
>  -> early_init_devtree(c000000007723000)
> Invalid tag 5 scanning flattened device tree !
> search "chosen", depth: 0, uname:
> Invalid tag 5 scanning flattened device tree !
> dt_root_size_cells = 2
> dt_root_addr_cells = 2
> Invalid tag 5 scanning flattened device tree !
> reserving: 128c000 -> 5ec1f7
> reserving: 7734000 -> 8cc000
> reserving: 7723000 -> f698
> Phys. mem: 0
> -> move_device_tree
> <- move_device_tree
> Scanning CPUs ...
> Invalid tag 5 scanning flattened device tree !
>  <- early_init_devtree()
> Probing machine type ...
>   pSeries ...
> No suitable machine found !
(Continue reading)

Eric W. Biederman | 7 Aug 21:50 2009

Re: [Patch 0/7] Implement crashkernel=auto


Let me put this concrete proposal on the table.

The problem:

With the current set of crashkernel= options we are asking the
distribution installer to perform magic.  Moving as much of this logic
into a normal init script for better maintenance is desirable.

My proposal:

Implement crashkernel=max which reserves as much memory as is
reasonable for a crash kernel, without seriously affecting stability,
performance, and reliability.

As an initial approximation I would use a 32nd of low memory.

In addition implement:

/sys/kernel/crash_size

That can be written to (with enough privileges when no crash kernel is
loaded) reduce the amount of memory reserved by the crash kernel.

Bernhard does that sound useful to you?

Amerigo does that seem reasonable?

Eric
--
(Continue reading)

Andi Kleen | 7 Aug 23:03 2009

Re: [Patch 0/7] Implement crashkernel=auto

> As an initial approximation I would use a 32nd of low memory.

That means a 1TB machine will have a 32GB crash kernel.

Surely that's excessive?!?

It would be repeating all the same mistakes people made with hash tables
several years ago.

> 
> That can be written to (with enough privileges when no crash kernel is
> loaded) reduce the amount of memory reserved by the crash kernel.
> 
> Bernhard does that sound useful to you?
> 
> Amerigo does that seem reasonable?

It doesn't sound reasonable to Andi.

Why do you even want to grow the crash kernel that much? Is there
any real problem with a 64-128MB crash kernel?

-Andi
> 

--

-- 
ak <at> linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Bernhard Walle | 7 Aug 23:26 2009
Picon
Picon

Re: [Patch 0/7] Implement crashkernel=auto

Andi Kleen schrieb:
>> As an initial approximation I would use a 32nd of low memory.
> 
> That means a 1TB machine will have a 32GB crash kernel.
> 
> Surely that's excessive?!?
> 
> It would be repeating all the same mistakes people made with hash tables
> several years ago.

The idea of Eric was to shrink the reserved memory in an init script. I
doubt that the 1 TB machine will have any problems or performance issue
when booting with (1 TB - 32 GB) memory.

> It doesn't sound reasonable to Andi.
> 
> Why do you even want to grow the crash kernel that much? Is there
> any real problem with a 64-128MB crash kernel?

Try it out. No chance for 64-128MB crashkernel on "medium" IA64 machines.

Regards,
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bernhard Walle | 7 Aug 23:31 2009
Picon
Picon

Re: [Patch 0/7] Implement crashkernel=auto

Eric W. Biederman schrieb:
> 
> With the current set of crashkernel= options we are asking the
> distribution installer to perform magic.  Moving as much of this logic
> into a normal init script for better maintenance is desirable.

Not (necessarily) the installer but the program that configures kdump.
system-config-kdump on Red Hat, YaST on SUSE.

> Bernhard does that sound useful to you?

I don't see any problems. I don't know how much effort is it to free
already reserved crashkernel memory, but I guess it's not really
complicated. Maybe that "1/32" should be specified on the command line like

	crashkernel=>>5

(for 1/32*system_memory == system_memory>>5), OTOH I have no real strong
opinion.

Regards,
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Eric W. Biederman | 8 Aug 00:06 2009

Re: [Patch 0/7] Implement crashkernel=auto

Andi Kleen <andi <at> firstfloor.org> writes:

>> As an initial approximation I would use a 32nd of low memory.
>
> That means a 1TB machine will have a 32GB crash kernel.
>
> Surely that's excessive?!?
>
> It would be repeating all the same mistakes people made with hash tables
> several years ago.
>
>> 
>> That can be written to (with enough privileges when no crash kernel is
>> loaded) reduce the amount of memory reserved by the crash kernel.
>> 
>> Bernhard does that sound useful to you?
>> 
>> Amerigo does that seem reasonable?
>
> It doesn't sound reasonable to Andi.
>
> Why do you even want to grow the crash kernel that much? Is there
> any real problem with a 64-128MB crash kernel?

Because it is absolutely ridiculous in size and user space will have
to take up the work of trimming back down to something reasonable in
the init script.

At a practical level crash dump userlands do things like fsck
filesystems before they mount them.  For truly large machines there
(Continue reading)


Gmane