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

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

[Simon Horman]

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Simon Horman]

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

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Paul Mundt]

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?

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Paul Mundt]

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?

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Simon Horman]

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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Simon Horman]

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

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Paul Mundt]

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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Paul Mundt]

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.

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Simon Horman]

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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] [RFC] sh: kexec: Register crashk_res

[Simon Horman]

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.