arch/cris/arch-v10/vmlinux.lds.S
fix boot problem
* too old initcall style. replace INITCALLS macro
* __init_begin, __init_end move for free_initmem()
Note: with this patch kernel boot and mount root,
but after init done, kernel panic at do_signal() ...
ryu
Signed-off-by: Yuusei KUWANA <[email protected]>
---
arch/cris/arch-v10/vmlinux.lds.S | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
index 9859d49..c5bab0e 100644
--- a/arch/cris/arch-v10/vmlinux.lds.S
+++ b/arch/cris/arch-v10/vmlinux.lds.S
@@ -53,26 +53,22 @@ SECTIONS
.data.init_task : { *(.data.init_task) }
. = ALIGN(8192); /* Init code and data */
- __init_begin = .;
.init.text : {
_sinittext = .;
*(.init.text)
_einittext = .;
}
+ __init_begin = .;
.init.data : { *(.init.data) }
+ __init_end = .;
+
. = ALIGN(16);
__setup_start = .;
.init.setup : { *(.init.setup) }
__setup_end = .;
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init);
- *(.initcall2.init);
- *(.initcall3.init);
- *(.initcall4.init);
- *(.initcall5.init);
- *(.initcall6.init);
- *(.initcall7.init);
+ INITCALLS
__initcall_end = .;
}
@@ -97,7 +93,6 @@ SECTIONS
#endif
__vmlinux_end = .; /* last address of the physical file */
- __init_end = .;
__data_end = . ; /* Move to _edata ? */
__bss_start = .; /* BSS */
--
1.5.3
On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> arch/cris/arch-v10/vmlinux.lds.S
> fix boot problem
> * too old initcall style. replace INITCALLS macro
> * __init_begin, __init_end move for free_initmem()
Hi,
The conversion to INITCALLS is ok (I have the same change here),
but I'm curious what problem you are solving with moving __init_begin and
__init_end to only include the .init.data.
If there is use of initcalls/data outside init then that is a bug and
should be fixed, not worked around.
There might however be another problem that Mikael Starvik told me about,
the padding between initdata and the next section had gone AWOL,
which made the free_initmem() destroy useful data.
With the attached patch (and a lot of other patches) I am successful in
booting an Axis Devboard82+.
Could you please try the included patch and see if that solves your problem?
> Note: with this patch kernel boot and mount root,
> but after init done, kernel panic at do_signal() ...
I have a patch in the pipe that should fix this, will send it in just
a small while.
> ryu
Thank you for your help!
Best regards,
/Jesper
> Signed-off-by: Yuusei KUWANA <[email protected]>
> ---
> arch/cris/arch-v10/vmlinux.lds.S | 13 ++++---------
> 1 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
> index 9859d49..c5bab0e 100644
> --- a/arch/cris/arch-v10/vmlinux.lds.S
> +++ b/arch/cris/arch-v10/vmlinux.lds.S
> @@ -53,26 +53,22 @@ SECTIONS
> .data.init_task : { *(.data.init_task) }
>
> . = ALIGN(8192); /* Init code and data */
> - __init_begin = .;
> .init.text : {
> _sinittext = .;
> *(.init.text)
> _einittext = .;
> }
> + __init_begin = .;
> .init.data : { *(.init.data) }
> + __init_end = .;
> +
> . = ALIGN(16);
> __setup_start = .;
> .init.setup : { *(.init.setup) }
> __setup_end = .;
> .initcall.init : {
> __initcall_start = .;
> - *(.initcall1.init);
> - *(.initcall2.init);
> - *(.initcall3.init);
> - *(.initcall4.init);
> - *(.initcall5.init);
> - *(.initcall6.init);
> - *(.initcall7.init);
> + INITCALLS
> __initcall_end = .;
> }
>
> @@ -97,7 +93,6 @@ SECTIONS
> #endif
>
> __vmlinux_end = .; /* last address of the physical file */
> - __init_end = .;
>
> __data_end = . ; /* Move to _edata ? */
> __bss_start = .; /* BSS */
> --
> 1.5.3
diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
index 9859d49..30fa872 100644
--- a/arch/cris/arch-v10/vmlinux.lds.S
+++ b/arch/cris/arch-v10/vmlinux.lds.S
@@ -23,7 +23,7 @@ SECTIONS
_stext = .;
__stext = .;
.text : {
- *(.text)
+ TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
*(.fixup)
@@ -66,13 +66,7 @@ SECTIONS
__setup_end = .;
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init);
- *(.initcall2.init);
- *(.initcall3.init);
- *(.initcall4.init);
- *(.initcall5.init);
- *(.initcall6.init);
- *(.initcall7.init);
+ INIT_CALLS
__initcall_end = .;
}
@@ -88,11 +82,15 @@ SECTIONS
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
- /* We fill to the next page, so we can discard all init
- pages without needing to consider what payload might be
- appended to the kernel image. */
- FILL (0);
- . = ALIGN (8192);
+ /*
+ * We fill to the next page, so we can discard all init
+ * pages without needing to consider what payload might be
+ * appended to the kernel image.
+ */
+ .init.fill : {
+ FILL (0);
+ . = ALIGN (8192);
+ }
}
#endif
/^JN - Jesper Nilsson
--
Jesper Nilsson -- [email protected]
...and of course I got a spurious "_" pasted into INITCALLS. Argh.
Corrected patch below.
diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
index 9859d49..ac98b2a 100644
--- a/arch/cris/arch-v10/vmlinux.lds.S
+++ b/arch/cris/arch-v10/vmlinux.lds.S
@@ -23,7 +23,7 @@ SECTIONS
_stext = .;
__stext = .;
.text : {
- *(.text)
+ TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
*(.fixup)
@@ -66,13 +66,7 @@ SECTIONS
__setup_end = .;
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init);
- *(.initcall2.init);
- *(.initcall3.init);
- *(.initcall4.init);
- *(.initcall5.init);
- *(.initcall6.init);
- *(.initcall7.init);
+ INITCALLS
__initcall_end = .;
}
@@ -88,11 +82,16 @@ SECTIONS
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
- /* We fill to the next page, so we can discard all init
- pages without needing to consider what payload might be
- appended to the kernel image. */
- FILL (0);
- . = ALIGN (8192);
+
+ /*
+ * We fill to the next page, so we can discard all init
+ * pages without needing to consider what payload might be
+ * appended to the kernel image.
+ */
+ .init.fill : {
+ FILL (0);
+ . = ALIGN (8192);
+ }
}
#endif
On Fri, Dec 21, 2007 at 04:14:04PM +0100, Jesper Nilsson wrote:
>
> On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> > arch/cris/arch-v10/vmlinux.lds.S
> > fix boot problem
> > * too old initcall style. replace INITCALLS macro
> > * __init_begin, __init_end move for free_initmem()
>
> Hi,
>
> The conversion to INITCALLS is ok (I have the same change here),
> but I'm curious what problem you are solving with moving __init_begin and
> __init_end to only include the .init.data.
>
> If there is use of initcalls/data outside init then that is a bug and
> should be fixed, not worked around.
>
> There might however be another problem that Mikael Starvik told me about,
> the padding between initdata and the next section had gone AWOL,
> which made the free_initmem() destroy useful data.
>
> With the attached patch (and a lot of other patches) I am successful in
> booting an Axis Devboard82+.
> Could you please try the included patch and see if that solves your problem?
>
> > Note: with this patch kernel boot and mount root,
> > but after init done, kernel panic at do_signal() ...
>
> I have a patch in the pipe that should fix this, will send it in just
> a small while.
>
> > ryu
>
> Thank you for your help!
>
> Best regards,
>
> /Jesper
/^JN - Jesper Nilsson
--
Jesper Nilsson -- [email protected]
Argh. Not my day, hopefully this is the last revision of the patch.
Best regards,
/Jesper
diff --git a/arch/cris/arch-v10/vmlinux.lds.S b/arch/cris/arch-v10/vmlinux.lds.S
index 9859d49..2afe1bd 100644
--- a/arch/cris/arch-v10/vmlinux.lds.S
+++ b/arch/cris/arch-v10/vmlinux.lds.S
@@ -23,7 +23,7 @@ SECTIONS
_stext = .;
__stext = .;
.text : {
- *(.text)
+ TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
*(.fixup)
@@ -66,13 +66,7 @@ SECTIONS
__setup_end = .;
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init);
- *(.initcall2.init);
- *(.initcall3.init);
- *(.initcall4.init);
- *(.initcall5.init);
- *(.initcall6.init);
- *(.initcall7.init);
+ INITCALLS
__initcall_end = .;
}
@@ -88,16 +82,21 @@ SECTIONS
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
- /* We fill to the next page, so we can discard all init
- pages without needing to consider what payload might be
- appended to the kernel image. */
- FILL (0);
- . = ALIGN (8192);
}
#endif
-
__vmlinux_end = .; /* last address of the physical file */
- __init_end = .;
+
+ /*
+ * We fill to the next page, so we can discard all init
+ * pages without needing to consider what payload might be
+ * appended to the kernel image.
+ */
+ .init.fill : {
+ FILL (0);
+ . = ALIGN (8192);
+ }
+
+ __init_end = .;
__data_end = . ; /* Move to _edata ? */
__bss_start = .; /* BSS */
> On Fri, Dec 21, 2007 at 04:14:04PM +0100, Jesper Nilsson wrote:
> >
> > On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> > > arch/cris/arch-v10/vmlinux.lds.S
> > > fix boot problem
> > > * too old initcall style. replace INITCALLS macro
> > > * __init_begin, __init_end move for free_initmem()
> >
> > Hi,
> >
> > The conversion to INITCALLS is ok (I have the same change here),
> > but I'm curious what problem you are solving with moving __init_begin and
> > __init_end to only include the .init.data.
> >
> > If there is use of initcalls/data outside init then that is a bug and
> > should be fixed, not worked around.
> >
> > There might however be another problem that Mikael Starvik told me about,
> > the padding between initdata and the next section had gone AWOL,
> > which made the free_initmem() destroy useful data.
> >
> > With the attached patch (and a lot of other patches) I am successful in
> > booting an Axis Devboard82+.
> > Could you please try the included patch and see if that solves your problem?
> >
> > > Note: with this patch kernel boot and mount root,
> > > but after init done, kernel panic at do_signal() ...
> >
> > I have a patch in the pipe that should fix this, will send it in just
> > a small while.
> >
> > > ryu
> >
> > Thank you for your help!
> >
> > Best regards,
> >
> > /Jesper
>
> /^JN - Jesper Nilsson
> --
> Jesper Nilsson -- [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
/^JN - Jesper Nilsson
--
Jesper Nilsson -- [email protected]
Hi Jesper.
> __initramfs_end = .;
> - /* We fill to the next page, so we can discard all init
> - pages without needing to consider what payload might be
> - appended to the kernel image. */
> - FILL (0);
> - . = ALIGN (8192);
> }
> #endif
> -
> __vmlinux_end = .; /* last address of the physical file */
> - __init_end = .;
> +
> + /*
> + * We fill to the next page, so we can discard all init
> + * pages without needing to consider what payload might be
> + * appended to the kernel image.
> + */
> + .init.fill : {
> + FILL (0);
> + . = ALIGN (8192);
> + }
> +
> + __init_end = .;
Can we please have the hardcoded 8192 replaced with a proper constant.
I assume this is PAGESIZE?
See hwat other archs does to make PAGESIZE available for assembly
files and ldscripts. The macro AC is the key point here.
And then please explain why it make a diffrence to put the
alignment in a section like you do.
I do not see it used in the other archs.
Sam
On Sat, Dec 22, 2007 at 09:37:17AM +0100, Sam Ravnborg wrote:
> Hi Jesper.
>
> > __initramfs_end = .;
> > - /* We fill to the next page, so we can discard all init
> > - pages without needing to consider what payload might be
> > - appended to the kernel image. */
> > - FILL (0);
> > - . = ALIGN (8192);
> > }
> > #endif
> > -
> > __vmlinux_end = .; /* last address of the physical file */
> > - __init_end = .;
> > +
> > + /*
> > + * We fill to the next page, so we can discard all init
> > + * pages without needing to consider what payload might be
> > + * appended to the kernel image.
> > + */
> > + .init.fill : {
> > + FILL (0);
> > + . = ALIGN (8192);
> > + }
> > +
> > + __init_end = .;
>
> Can we please have the hardcoded 8192 replaced with a proper constant.
> I assume this is PAGESIZE?
Yes, quite so.
> See hwat other archs does to make PAGESIZE available for assembly
> files and ldscripts. The macro AC is the key point here.
Ok, will do.
> And then please explain why it make a diffrence to put the
> alignment in a section like you do.
> I do not see it used in the other archs.
I'm not an expert on ld-scripts, so I only know that the linker didn't
respect the other way of doing the alignment, but did when added in a
section.
Perhaps Mikael has a better explanation when he's back from vacation.
> Sam
Best regards,
/^JN - Jesper Nilsson
--
Jesper Nilsson -- [email protected]