[PATCH] [RFC] sh: kexec: Register crashk

SUPERH platform development
 help / color / mirror / Atom feed

* [PATCH] [RFC] sh: kexec: Register crashk_res
@ 2011-09-02  3:47 Simon Horman
  2011-09-05  3:23 ` Paul Mundt
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Simon Horman @ 2011-09-02  3:47 UTC (permalink / raw)
  To: linux-sh

Register crashk_res so that it can be used by kexec-tools
via /proc/iomem.

On x86 the registration occurs using
insert_resource(&iomem_resource, &crashk_res).
However that approach seems to result in the boot hanging on SH.

Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/sh/kernel/setup.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 58bff45..6d566bb 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -211,13 +211,16 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn,
 	}
 
 	/*
-	 *  We don't know which RAM region contains kernel data,
-	 *  so we try it repeatedly and let the resource manager
-	 *  test it.
+	 *  We don't know which RAM region contains kernel data or
+	 *  the reserved crashkernel region, so try it repeatedly
+	 *  and let the resource manager test it.
 	 */
 	request_resource(res, &code_resource);
 	request_resource(res, &data_resource);
 	request_resource(res, &bss_resource);
+#ifdef CONFIG_KEXEC
+	request_resource(res, &crashk_res);
+#endif
 
 	/*
 	 * Also make sure that there is a PMB mapping that covers this
-- 
1.7.5.4


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] [RFC] sh: kexec: Register crashk_res
  2011-09-02  3:47 [PATCH] [RFC] sh: kexec: Register crashk_res Simon Horman
@ 2011-09-05  3:23 ` Paul Mundt
  2011-09-05  4:25 ` Simon Horman
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2011-09-05  3:23 UTC (permalink / raw)
  To: linux-sh

On Fri, Sep 02, 2011 at 12:47:12PM +0900, Simon Horman wrote:
> Register crashk_res so that it can be used by kexec-tools
> via /proc/iomem.
> 
> On x86 the registration occurs using
> insert_resource(&iomem_resource, &crashk_res).
> However that approach seems to result in the boot hanging on SH.
> 
> Signed-off-by: Simon Horman <horms@verge.net.au>

x86 has a slightly more straightforward registration method. We end up
going through the same path for all memory ranges, which also
encapsulates the NUMA case. As such, we don't necessarily know which
range will contain the resource in question, so it's attempted on each
range addition, expecting the resource manager to work things out for us.

With the request_resource() in place you presumably see the crash kernel
resource where you expect it to in /proc/iomem?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] [RFC] sh: kexec: Register crashk_res
  2011-09-02  3:47 [PATCH] [RFC] sh: kexec: Register crashk_res Simon Horman
  2011-09-05  3:23 ` Paul Mundt
@ 2011-09-05  4:25 ` Simon Horman
  2011-09-05  4:36 ` Paul Mundt
  2011-09-05  5:30 ` Simon Horman
  3 siblings, 0 replies; 5+ messages in thread
From: Simon Horman @ 2011-09-05  4:25 UTC (permalink / raw)
  To: linux-sh

On Mon, Sep 05, 2011 at 12:23:53PM +0900, Paul Mundt wrote:
> On Fri, Sep 02, 2011 at 12:47:12PM +0900, Simon Horman wrote:
> > Register crashk_res so that it can be used by kexec-tools
> > via /proc/iomem.
> > 
> > On x86 the registration occurs using
> > insert_resource(&iomem_resource, &crashk_res).
> > However that approach seems to result in the boot hanging on SH.
> > 
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> x86 has a slightly more straightforward registration method. We end up
> going through the same path for all memory ranges, which also
> encapsulates the NUMA case. As such, we don't necessarily know which
> range will contain the resource in question, so it's attempted on each
> range addition, expecting the resource manager to work things out for us.
> 
> With the request_resource() in place you presumably see the crash kernel
> resource where you expect it to in /proc/iomem?

Yes. With this patch in place the crash kernel resource
shows up in /proc/iomem in a sensible way.

# cat /proc/iomem 
40000000-4effffff : System RAM
 40001000-402dbfc7 : Kernel code
 402dbfc8-403cd51f : Kernel data
 40553000-40568c5b : Kernel bss
 4d000000-4effffff : Crash kernel
...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] [RFC] sh: kexec: Register crashk_res
  2011-09-02  3:47 [PATCH] [RFC] sh: kexec: Register crashk_res Simon Horman
  2011-09-05  3:23 ` Paul Mundt
  2011-09-05  4:25 ` Simon Horman
@ 2011-09-05  4:36 ` Paul Mundt
  2011-09-05  5:30 ` Simon Horman
  3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2011-09-05  4:36 UTC (permalink / raw)
  To: linux-sh

On Mon, Sep 05, 2011 at 01:25:50PM +0900, Simon Horman wrote:
> On Mon, Sep 05, 2011 at 12:23:53PM +0900, Paul Mundt wrote:
> > On Fri, Sep 02, 2011 at 12:47:12PM +0900, Simon Horman wrote:
> > > Register crashk_res so that it can be used by kexec-tools
> > > via /proc/iomem.
> > > 
> > > On x86 the registration occurs using
> > > insert_resource(&iomem_resource, &crashk_res).
> > > However that approach seems to result in the boot hanging on SH.
> > > 
> > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > 
> > x86 has a slightly more straightforward registration method. We end up
> > going through the same path for all memory ranges, which also
> > encapsulates the NUMA case. As such, we don't necessarily know which
> > range will contain the resource in question, so it's attempted on each
> > range addition, expecting the resource manager to work things out for us.
> > 
> > With the request_resource() in place you presumably see the crash kernel
> > resource where you expect it to in /proc/iomem?
> 
> Yes. With this patch in place the crash kernel resource
> shows up in /proc/iomem in a sensible way.
> 
> # cat /proc/iomem 
> 40000000-4effffff : System RAM
>  40001000-402dbfc7 : Kernel code
>  402dbfc8-403cd51f : Kernel data
>  40553000-40568c5b : Kernel bss
>  4d000000-4effffff : Crash kernel
> ...

Ok, I've queued it up with a slightly more verbose changelog. I'll send
it along for 3.1 so kexec-tools doesn't remain blocked.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] [RFC] sh: kexec: Register crashk_res
  2011-09-02  3:47 [PATCH] [RFC] sh: kexec: Register crashk_res Simon Horman
                   ` (2 preceding siblings ...)
  2011-09-05  4:36 ` Paul Mundt
@ 2011-09-05  5:30 ` Simon Horman
  3 siblings, 0 replies; 5+ messages in thread
From: Simon Horman @ 2011-09-05  5:30 UTC (permalink / raw)
  To: linux-sh

On Mon, Sep 05, 2011 at 01:36:27PM +0900, Paul Mundt wrote:
> On Mon, Sep 05, 2011 at 01:25:50PM +0900, Simon Horman wrote:
> > On Mon, Sep 05, 2011 at 12:23:53PM +0900, Paul Mundt wrote:
> > > On Fri, Sep 02, 2011 at 12:47:12PM +0900, Simon Horman wrote:
> > > > Register crashk_res so that it can be used by kexec-tools
> > > > via /proc/iomem.
> > > > 
> > > > On x86 the registration occurs using
> > > > insert_resource(&iomem_resource, &crashk_res).
> > > > However that approach seems to result in the boot hanging on SH.
> > > > 
> > > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > > 
> > > x86 has a slightly more straightforward registration method. We end up
> > > going through the same path for all memory ranges, which also
> > > encapsulates the NUMA case. As such, we don't necessarily know which
> > > range will contain the resource in question, so it's attempted on each
> > > range addition, expecting the resource manager to work things out for us.
> > > 
> > > With the request_resource() in place you presumably see the crash kernel
> > > resource where you expect it to in /proc/iomem?
> > 
> > Yes. With this patch in place the crash kernel resource
> > shows up in /proc/iomem in a sensible way.
> > 
> > # cat /proc/iomem 
> > 40000000-4effffff : System RAM
> >  40001000-402dbfc7 : Kernel code
> >  402dbfc8-403cd51f : Kernel data
> >  40553000-40568c5b : Kernel bss
> >  4d000000-4effffff : Crash kernel
> > ...
> 
> Ok, I've queued it up with a slightly more verbose changelog. I'll send
> it along for 3.1 so kexec-tools doesn't remain blocked.

Thanks.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-09-05  5:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-02  3:47 [PATCH] [RFC] sh: kexec: Register crashk_res Simon Horman
2011-09-05  3:23 ` Paul Mundt
2011-09-05  4:25 ` Simon Horman
2011-09-05  4:36 ` Paul Mundt
2011-09-05  5:30 ` Simon Horman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox