| Message ID | 1314935232-1545-1-git-send-email-horms@verge.net.au (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d6a93d562f4bb30bf83081d740f40c03ed9e3996 |
| Headers | show |
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? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ... -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(-)