Re: Patch "i386: Relocatable kernel support" causes instant reboot

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Jean Delvare <khali@linux-fr.org> writes:

> Hi Eric, Vivek, Andi,
>
> One of my test machines (i586, Asus P4P800-X) reboots instantly when I
> try to boot a 2.6.20-rc1 kernel. 2.6.19 and 2.6.19.1 boot OK. I ran a
> git bisect and it pointed me to this patch:

I don't think this is a know issue.

The most straight forward way to debug this is to put infinite
loops in arch/i386/boot/compressed/head.S moving progressively farther
in until you find where the line in head.S that the machine reboots
on you is.

Although it is possible the problem falls in misc.c as well.

If you have a serial console setup we can probably make this
process a little easier.

One hunch is that we did something stupid, and have an instruction
that only executes on an i686 in there somewhere.

> After that the machine boots OK again. Note that I did _not_ enable
> RELOCATABLE. This is admitedly an old system with an old boot loader
> (lilo 22.5.7.2), so if that's a known issue, I'll be happy to install
> something newer. If not, I am willing to provide all the information
> needed to fix the bug.

Thanks.

Eric

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Jean Delvare <khali@linux-fr.org> writes:

> Hi Eric,
>
> On Wed, 20 Dec 2006 07:00:11 -0700, Eric W. Biederman wrote:
>> Jean Delvare writes:
>> > One of my test machines (i586, Asus P4P800-X) reboots instantly when I
>> > try to boot a 2.6.20-rc1 kernel. 2.6.19 and 2.6.19.1 boot OK. I ran a
>> > git bisect and it pointed me to this patch:
>> 
>> I don't think this is a know issue.
>> 
>> The most straight forward way to debug this is to put infinite
>> loops in arch/i386/boot/compressed/head.S moving progressively farther
>> in until you find where the line in head.S that the machine reboots
>> on you is.
>
> I could try that with some guidance. What instructions should I insert
> to create an infinite loop?

10: jmp 10b
Should do it, but see below.

>> Although it is possible the problem falls in misc.c as well.
>> 
>> If you have a serial console setup we can probably make this
>> process a little easier.
>
> I can setup a serial console if needed, what are we looking for? Just
> to know where exactly the reboot happens?

Yes.  At this point I'm just trying to find a place to start.

I guess you likely have video on that machine so if we get into
misc.c and we stop rebooting you should be able to see some output.

You don't see the classic "decompressing kernel" message do you?

How big is your kernel?

You are booting a bzImage? not an ancient zImage?

>> One hunch is that we did something stupid, and have an instruction
>> that only executes on an i686 in there somewhere.
>
> This is a Pentium 4, I'm compiling for i586 for compatibility with my
> another test systems. So an i686 instruction would work fine, it has to
> be something else.

Ok.  That pretty much means something odd happened during the build
or there is some weird size issue.  What are the version of your
compiler and linker?


Ok.  Here is a small diff that inserts the infinite loops, between
each section of code in head.S  Procedurally please trying booting
this unmodified and see if it boots, then remove the infinite loop
until you come to the one where the system reboots instead of hangs.

That should at least give me a good idea of where to look.
If 20 hangs and 21 still reboots we are into misc.c and the
decompressor.  And I will have to ask something different.

Eric

diff --git a/arch/i386/boot/compressed/head.S b/arch/i386/boot/compressed/head.S
index f395a4b..f48a333 100644
--- a/arch/i386/boot/compressed/head.S
+++ b/arch/i386/boot/compressed/head.S
@@ -32,6 +32,7 @@
 	.globl startup_32
 
 startup_32:
+10:	jmp 10b	
 	cld
 	cli
 	movl $(__BOOT_DS),%eax
@@ -41,6 +42,7 @@ startup_32:
 	movl %eax,%gs
 	movl %eax,%ss
 
+11:	jmp 11b	
 /* Calculate the delta between where we were compiled to run
  * at and where we were actually loaded at.  This can only be done
  * with a short local call on x86.  Nothing  else will tell us what
@@ -53,6 +55,7 @@ startup_32:
 1:	popl %ebp
 	subl $1b, %ebp
 
+12:	jmp 12b	
 /* %ebp contains the address we are loaded at by the boot loader and %ebx
  * contains the address where we should move the kernel image temporarily
  * for safe in-place decompression.
@@ -66,6 +69,7 @@ startup_32:
 	movl $LOAD_PHYSICAL_ADDR, %ebx
 #endif
 
+13:	jmp 13b	
 	/* Replace the compressed data size with the uncompressed size */
 	subl input_len(%ebp), %ebx
 	movl output_len(%ebp), %eax
@@ -79,6 +83,7 @@ startup_32:
 	addl $4095, %ebx
 	andl $~4095, %ebx
 
+14:	jmp 14b	
 /* Copy the compressed kernel to the end of our buffer
  * where decompression in place becomes safe.
  */
@@ -92,6 +97,7 @@ startup_32:
 	cld
 	popl %esi
 
+15:	jmp 15b	
 /* Compute the kernel start address.
  */
 #ifdef CONFIG_RELOCATABLE
@@ -101,6 +107,7 @@ startup_32:
 	movl	$LOAD_PHYSICAL_ADDR, %ebp
 #endif
 
+16:	jmp 16b	
 /*
  * Jump to the relocated address.
  */
@@ -109,6 +116,7 @@ startup_32:
 .section ".text"
 relocated:
 
+17:	jmp 17b	
 /*
  * Clear BSS
  */
@@ -120,11 +128,13 @@ relocated:
 	rep
 	stosb
 
+18:	jmp 18b	
 /*
  * Setup the stack for the decompressor
  */
 	leal stack_end(%ebx), %esp
 
+19:	jmp 19b	
 /*
  * Do the decompression, and jump to the new kernel..
  */
@@ -138,16 +148,20 @@ relocated:
 	leal _end(%ebx), %eax
 	pushl %eax	# end of the image as third argument
 	pushl %esi	# real mode pointer as second arg
+20:	jmp 20b	
 	call decompress_kernel
+21:	jmp 21b	
 	addl $20, %esp
 	popl %ecx
 
+22:	jmp 22b	
 #if CONFIG_RELOCATABLE
 /* Find the address of the relocations.
  */
 	movl %ebp, %edi
 	addl %ecx, %edi
 
+23:	jmp 23b	
 /* Calculate the delta between where vmlinux was compiled to run
  * and where it was actually loaded.
  */
@@ -167,6 +181,7 @@ relocated:
 2:
 #endif
 
+24:	jmp 24b	
 /*
  * Jump to the decompressed kernel.
  */

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
> Jean Delvare <khali@linux-fr.org> writes:
> 
> > On Thu, 21 Dec 2006 10:12:40 +0100, Jean Delvare wrote:
> >> On Wed, 20 Dec 2006 15:22:20 -0700, Eric W. Biederman wrote:
> >> > Ok.  Here is a small diff that inserts the infinite loops, between
> >> > each section of code in head.S  Procedurally please trying booting
> >> > this unmodified and see if it boots, then remove the infinite loop
> >> > until you come to the one where the system reboots instead of hangs.
> >> >
> >> > That should at least give me a good idea of where to look.
> >> > If 20 hangs and 21 still reboots we are into misc.c and the
> >> > decompressor.  And I will have to ask something different.
> >>
> >> OK, I'll start the tests now, I'll let you know the outcome when I'm
> >> done.
> >
> > Hm, that was quick... Even with your unmodified patch, the machine
> > still reboots. Does that make any sense to you?
> >
> > I can try installing a more recent system on the same hardware if it
> > helps.
> 
> Grr.  I guessed the problem was to late in the game it seems the problem
> is in setup.S  Before we switch to 32bit mode.
> 
> Ok.  There is almost enough for inference but here is a patch of stops
> for setup.S let's see if one of those will stop the reboots.
> 
> I have a strong feeling that we are going to find a tool chain issue,
> but I'd like to find where we ware having problems before we declare
> that to be the case.
> 

Looks like it might be a tool chain issue. I took Jean's config file and
built my own kernel and I am able to boot the kernel. But I can't boot
his bzImage. I observed the same behaviour as jean is experiencing. It jumps
back to BIOS.

I am using grub 0.97. So any dependency on lilo can be ruled out in this
case.

Following is my software environment.

gcc version 4.1.1 20061130 (Red Hat 4.1.1-43)
GNU ld version 2.17.50.0.6-2.el5 20061020

I got Intel Xeon machine.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Xeon(TM) CPU 3.40GHz
stepping        : 3
cpu MHz         : 3400.483
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips        : 6805.59
clflush size    : 64

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 05:32:56AM -0700, Eric W. Biederman wrote:
> 
> Take a look at the diff for commit 968de4f02621db35b8ae5239c8cfc6664fb872d8
> of setup.S there are very few candidate instructions.
> 
> I suspect with a few minutes of review we should be able to see what the
> assembler is doing wrong and decide if we want to blacklist that assembler
> or work around it's bug.
> 
> diff --git a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
> index 3aec453..9aa8b05 100644
> --- a/arch/i386/boot/setup.S
> +++ b/arch/i386/boot/setup.S
> @@ -588,11 +588,6 @@ rmodeswtch_normal:
>         call    default_switch
> 
>  rmodeswtch_end:
> -# we get the code32 start address and modify the below 'jmpi'
> -# (loader may have changed it)
> -       movl    %cs:code32_start, %eax
> -       movl    %eax, %cs:code32
> -
>  # Now we move the system to its rightful place ... but we check if we have a
>  # big-kernel. In that case we *must* not move it ...
>         testb   $LOADED_HIGH, %cs:loadflags
> @@ -788,11 +783,12 @@ a20_err_msg:
>  a20_done:
> 
>  #endif /* CONFIG_X86_VOYAGER */
> -# set up gdt and idt
> +# set up gdt and idt and 32bit start address
>         lidt    idt_48                          # load idt with 0,0
>         xorl    %eax, %eax                      # Compute gdt_base
>         movw    %ds, %ax                        # (Convert %ds:gdt to a linear ptr)
>         shll    $4, %eax
> +       addl    %eax, code32
>         addl    $gdt, %eax
>         movl    %eax, (gdt_48+2)
>         lgdt    gdt_48                          # load gdt with whatever is
> @@ -851,9 +847,26 @@ flush_instr:
>  #      Manual, Mixing 16-bit and 32-bit code, page 16-6)
> 
>         .byte 0x66, 0xea                        # prefix + jmpi-opcode
> -code32:        .long   0x1000                          # will be set to 0x100000
> -                                               # for big kernels
> +code32:        .long   startup_32                      # will be set to %cs+startup_32
>         .word   __BOOT_CS
> +.code32
> +startup_32:
> +       movl $(__BOOT_DS), %eax
> +       movl %eax, %ds
> +       movl %eax, %es
> +       movl %eax, %fs
> +       movl %eax, %gs
> +       movl %eax, %ss
> +
> +       xorl %eax, %eax
> +1:     incl %eax                               # check that A20 really IS enabled
> +       movl %eax, 0x00000000                   # loop forever if it isn't
> +       cmpl %eax, 0x00100000
> +       je 1b
> +
> +       # Jump to the 32bit entry point
> +       jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi)

Hi Eric,

I got a basic query. Why have we introduced this additional jump to 
startup_32 in the same file? Won't it work if we stick to old method of
enabling protected mode and then directly taking a jmp to startup_32 in
arch/i386/kernel/head.S. Am I missing something obivious? 

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 02:13:54PM +0100, Jean Delvare wrote:
> On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> > On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
> > > Grr.  I guessed the problem was to late in the game it seems the problem
> > > is in setup.S  Before we switch to 32bit mode.
> > >
> > > Ok.  There is almost enough for inference but here is a patch of stops
> > > for setup.S let's see if one of those will stop the reboots.
> > >
> > > I have a strong feeling that we are going to find a tool chain issue,
> > > but I'd like to find where we ware having problems before we declare
> > > that to be the case.
> >
> > Looks like it might be a tool chain issue. I took Jean's config file and
> > built my own kernel and I am able to boot the kernel. But I can't boot
> > his bzImage. I observed the same behaviour as jean is experiencing. It jumps
> > back to BIOS.
> 
> I can only confirm that. I installed a more recent system on the same
> hardware, rebuilt a kernel from the same config file, and now it boots
> OK. So it's not related to the hardware. It has to be a compilation-time
> issue.
> 

Hi Jean,

Looks like you have already trashed your setup. If not, is it possible to
upload the output of "objdump -D arch/i386/boot/setup.o"? This will give
some info regarding what assembler is doing.

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 02:54:01PM +0100, Jean Delvare wrote:
> On Thu, 21 Dec 2006 03:32:33 -0700, Eric W. Biederman wrote:
> > Ok.  There is almost enough for inference but here is a patch of stops
> > for setup.S let's see if one of those will stop the reboots.
> >
> > I have a strong feeling that we are going to find a tool chain issue,
> > but I'd like to find where we ware having problems before we declare
> > that to be the case.
> > (...)
> > diff --git a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
> > index 06edf1c..2868020 100644
> > --- a/arch/i386/boot/setup.S
> > +++ b/arch/i386/boot/setup.S
> > @@ -795,6 +795,7 @@ a20_done:
> >
> >  #endif /* CONFIG_X86_VOYAGER */
> >  # set up gdt and idt and 32bit start address
> > +10: jmp	10b
> 
> Locked here, removed.
> 
> Out of curiosity, what does the "b" stand for?
> 

I think one can have multiple labels named as 10: so we need to specify
which one do you want to jump to. Either forward one (f) or backward
one (b).
 
[..]
> 
> Locked here, removed.
> 
> >  	# Jump to the 32bit entry point
> >  	jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi)
> >  .code16
> 
> Which brought me to the original situation, where unsurprisingly the
> reboot happened. So the problem is located after label 14. Does it help?
>

Ok. so indirect jump seems to be having problem. On my machine disassembly
of setup.o show following.

ff a6 14 02 00 00       jmp    *0x214(%esi)

This seems to be fine as 0x14 is the offset of code32_start, and 
((DELTA_INITSEG) << 4) is 0x200. How does it look like on your machine?

Thanks
Vivek
  

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 07:56:01AM +0530, Vivek Goyal wrote:
[..]
> >  #      Manual, Mixing 16-bit and 32-bit code, page 16-6)
> > 
> >         .byte 0x66, 0xea                        # prefix + jmpi-opcode
> > -code32:        .long   0x1000                          # will be set to 0x100000
> > -                                               # for big kernels
> > +code32:        .long   startup_32                      # will be set to %cs+startup_32
> >         .word   __BOOT_CS
> > +.code32
> > +startup_32:
> > +       movl $(__BOOT_DS), %eax
> > +       movl %eax, %ds
> > +       movl %eax, %es
> > +       movl %eax, %fs
> > +       movl %eax, %gs
> > +       movl %eax, %ss
> > +
> > +       xorl %eax, %eax
> > +1:     incl %eax                               # check that A20 really IS enabled
> > +       movl %eax, 0x00000000                   # loop forever if it isn't
> > +       cmpl %eax, 0x00100000
> > +       je 1b
> > +
> > +       # Jump to the 32bit entry point
> > +       jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi)
> 
> Hi Eric,
> 
> I got a basic query. Why have we introduced this additional jump to 
> startup_32 in the same file? Won't it work if we stick to old method of
> enabling protected mode and then directly taking a jmp to startup_32 in
> arch/i386/kernel/head.S. Am I missing something obivious? 
> 

Sorry, I meant arch/i386/boot/compressed/head.S and not arch/i386/kernel/head.S

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Wed, Dec 20, 2006 at 09:43:40PM +0100, Jean Delvare wrote:
> Hi Eric,
> 
> On Wed, 20 Dec 2006 07:00:11 -0700, Eric W. Biederman wrote:
> > Jean Delvare writes:
> > > One of my test machines (i586, Asus P4P800-X) reboots instantly when I
> > > try to boot a 2.6.20-rc1 kernel. 2.6.19 and 2.6.19.1 boot OK. I ran a
> > > git bisect and it pointed me to this patch:
> >
> > I don't think this is a know issue.
> >
> > The most straight forward way to debug this is to put infinite
> > loops in arch/i386/boot/compressed/head.S moving progressively farther
> > in until you find where the line in head.S that the machine reboots
> > on you is.
> 
> I could try that with some guidance. What instructions should I insert
> to create an infinite loop?
> 
> > Although it is possible the problem falls in misc.c as well.
> >
> > If you have a serial console setup we can probably make this
> > process a little easier.
> 
> I can setup a serial console if needed, what are we looking for? Just
> to know where exactly the reboot happens?
> 
> > One hunch is that we did something stupid, and have an instruction
> > that only executes on an i686 in there somewhere.
> 
> This is a Pentium 4, I'm compiling for i586 for compatibility with my
> another test systems. So an i686 instruction would work fine, it has to
> be something else.
> 

Hi Jean,

What's the value of CONFIG_PHYSICAL_ALIGN? How much RAM is present in your
system? Though very unlikely, just trying to find that we are not running
short of RAM while trying to align the kernel to a large value.

Can you please provide your config file. Is it possible to provide your
bzImage? Can you upload it somewhere? Will try to boot it on my box just
to find out if it could be in some way related to compiler/linker.

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Thu, 21 Dec 2006 10:11:26 +0530, Vivek Goyal wrote:
> What's the value of CONFIG_PHYSICAL_ALIGN? How much RAM is present in your
> system? Though very unlikely, just trying to find that we are not running
> short of RAM while trying to align the kernel to a large value.

CONFIG_PHYSICAL_ALIGN=0x100000
(which is the default as far as I know)
The system has 512 MB RAM.

> Can you please provide your config file. Is it possible to provide your
> bzImage? Can you upload it somewhere? Will try to boot it on my box just
> to find out if it could be in some way related to compiler/linker.

http://jdelvare.pck.nerim.net/linux/relocatable-bug/

gcc version is 3.2.3
ld version is 2.14.90.0.6

Thanks,
-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Jean Delvare <khali@linux-fr.org> writes:

> On Thu, 21 Dec 2006 10:12:40 +0100, Jean Delvare wrote:
>> On Wed, 20 Dec 2006 15:22:20 -0700, Eric W. Biederman wrote:
>> > Ok.  Here is a small diff that inserts the infinite loops, between
>> > each section of code in head.S  Procedurally please trying booting
>> > this unmodified and see if it boots, then remove the infinite loop
>> > until you come to the one where the system reboots instead of hangs.
>> > 
>> > That should at least give me a good idea of where to look.
>> > If 20 hangs and 21 still reboots we are into misc.c and the
>> > decompressor.  And I will have to ask something different.
>> 
>> OK, I'll start the tests now, I'll let you know the outcome when I'm
>> done.
>
> Hm, that was quick... Even with your unmodified patch, the machine
> still reboots. Does that make any sense to you?
>
> I can try installing a more recent system on the same hardware if it
> helps.

Grr.  I guessed the problem was to late in the game it seems the problem
is in setup.S  Before we switch to 32bit mode.

Ok.  There is almost enough for inference but here is a patch of stops
for setup.S let's see if one of those will stop the reboots.

I have a strong feeling that we are going to find a tool chain issue,
but I'd like to find where we ware having problems before we declare
that to be the case.


Eric

diff --git a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
index 06edf1c..2868020 100644
--- a/arch/i386/boot/setup.S
+++ b/arch/i386/boot/setup.S
@@ -795,6 +795,7 @@ a20_done:
 
 #endif /* CONFIG_X86_VOYAGER */
 # set up gdt and idt and 32bit start address
+10: jmp	10b
 	lidt	idt_48				# load idt with 0,0
 	xorl	%eax, %eax			# Compute gdt_base
 	movw	%ds, %ax			# (Convert %ds:gdt to a linear ptr)
@@ -846,6 +847,7 @@ flush_instr:
 	subw	$DELTA_INITSEG, %si
 	shll	$4, %esi			# Convert to 32-bit pointer
 
+11: jmp	11b
 # jump to startup_32 in arch/i386/boot/compressed/head.S
 #	
 # NOTE: For high loaded big kernels we need a
@@ -862,6 +864,7 @@ code32:	.long	startup_32			# will be set to %cs+startup_32
 	.word	__BOOT_CS
 .code32
 startup_32:
+12: jmp	12b
 	movl $(__BOOT_DS), %eax
 	movl %eax, %ds
 	movl %eax, %es
@@ -869,12 +872,14 @@ startup_32:
 	movl %eax, %gs
 	movl %eax, %ss
 
+13: jmp	13b
 	xorl %eax, %eax
 1:	incl %eax				# check that A20 really IS enabled
 	movl %eax, 0x00000000			# loop forever if it isn't
 	cmpl %eax, 0x00100000
 	je 1b
 
+14: jmp	14b
 	# Jump to the 32bit entry point
 	jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi)
 .code16

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
>> Jean Delvare <khali@linux-fr.org> writes:
>> 
>> > On Thu, 21 Dec 2006 10:12:40 +0100, Jean Delvare wrote:
>> >> On Wed, 20 Dec 2006 15:22:20 -0700, Eric W. Biederman wrote:
>> >> > Ok.  Here is a small diff that inserts the infinite loops, between
>> >> > each section of code in head.S  Procedurally please trying booting
>> >> > this unmodified and see if it boots, then remove the infinite loop
>> >> > until you come to the one where the system reboots instead of hangs.
>> >> >
>> >> > That should at least give me a good idea of where to look.
>> >> > If 20 hangs and 21 still reboots we are into misc.c and the
>> >> > decompressor.  And I will have to ask something different.
>> >>
>> >> OK, I'll start the tests now, I'll let you know the outcome when I'm
>> >> done.
>> >
>> > Hm, that was quick... Even with your unmodified patch, the machine
>> > still reboots. Does that make any sense to you?
>> >
>> > I can try installing a more recent system on the same hardware if it
>> > helps.
>> 
>> Grr.  I guessed the problem was to late in the game it seems the problem
>> is in setup.S  Before we switch to 32bit mode.
>> 
>> Ok.  There is almost enough for inference but here is a patch of stops
>> for setup.S let's see if one of those will stop the reboots.
>> 
>> I have a strong feeling that we are going to find a tool chain issue,
>> but I'd like to find where we ware having problems before we declare
>> that to be the case.
>> 
>
> Looks like it might be a tool chain issue. I took Jean's config file and
> built my own kernel and I am able to boot the kernel. But I can't boot
> his bzImage. I observed the same behaviour as jean is experiencing. It jumps
> back to BIOS.
>
> I am using grub 0.97. So any dependency on lilo can be ruled out in this
> case.
>
> Following is my software environment.
>
> gcc version 4.1.1 20061130 (Red Hat 4.1.1-43)
> GNU ld version 2.17.50.0.6-2.el5 20061020
>
> I got Intel Xeon machine.
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 4
> model name      : Intel(R) Xeon(TM) CPU 3.40GHz
> stepping        : 3
> cpu MHz         : 3400.483
> cache size      : 2048 KB
> physical id     : 0
> siblings        : 2
> core id         : 0
> cpu cores       : 1
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 5
> wp              : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor
> ds_cpl est cid cx16 xtpr
> bogomips        : 6805.59
> clflush size    : 64

Take a look at the diff for commit 968de4f02621db35b8ae5239c8cfc6664fb872d8
of setup.S there are very few candidate instructions.

I suspect with a few minutes of review we should be able to see what the
assembler is doing wrong and decide if we want to blacklist that assembler
or work around it's bug.

diff --git a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
index 3aec453..9aa8b05 100644
--- a/arch/i386/boot/setup.S
+++ b/arch/i386/boot/setup.S
@@ -588,11 +588,6 @@ rmodeswtch_normal:
        call    default_switch
 
 rmodeswtch_end:
-# we get the code32 start address and modify the below 'jmpi'
-# (loader may have changed it)
-       movl    %cs:code32_start, %eax
-       movl    %eax, %cs:code32
-
 # Now we move the system to its rightful place ... but we check if we have a
 # big-kernel. In that case we *must* not move it ...
        testb   $LOADED_HIGH, %cs:loadflags
@@ -788,11 +783,12 @@ a20_err_msg:
 a20_done:
 
 #endif /* CONFIG_X86_VOYAGER */
-# set up gdt and idt
+# set up gdt and idt and 32bit start address
        lidt    idt_48                          # load idt with 0,0
        xorl    %eax, %eax                      # Compute gdt_base
        movw    %ds, %ax                        # (Convert %ds:gdt to a linear ptr)
        shll    $4, %eax
+       addl    %eax, code32
        addl    $gdt, %eax
        movl    %eax, (gdt_48+2)
        lgdt    gdt_48                          # load gdt with whatever is
@@ -851,9 +847,26 @@ flush_instr:
 #      Manual, Mixing 16-bit and 32-bit code, page 16-6)
 
        .byte 0x66, 0xea                        # prefix + jmpi-opcode
-code32:        .long   0x1000                          # will be set to 0x100000
-                                               # for big kernels
+code32:        .long   startup_32                      # will be set to %cs+startup_32
        .word   __BOOT_CS
+.code32
+startup_32:
+       movl $(__BOOT_DS), %eax
+       movl %eax, %ds
+       movl %eax, %es
+       movl %eax, %fs
+       movl %eax, %gs
+       movl %eax, %ss
+
+       xorl %eax, %eax
+1:     incl %eax                               # check that A20 really IS enabled
+       movl %eax, 0x00000000                   # loop forever if it isn't
+       cmpl %eax, 0x00100000
+       je 1b
+
+       # Jump to the 32bit entry point
+       jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi)
+.code16
 
 # Here's a bunch of information about your current kernel..
 kernel_version:        .ascii  UTS_RELEASE

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
> > Grr.  I guessed the problem was to late in the game it seems the problem
> > is in setup.S  Before we switch to 32bit mode.
> > 
> > Ok.  There is almost enough for inference but here is a patch of stops
> > for setup.S let's see if one of those will stop the reboots.
> > 
> > I have a strong feeling that we are going to find a tool chain issue,
> > but I'd like to find where we ware having problems before we declare
> > that to be the case.
> 
> Looks like it might be a tool chain issue. I took Jean's config file and
> built my own kernel and I am able to boot the kernel. But I can't boot
> his bzImage. I observed the same behaviour as jean is experiencing. It jumps
> back to BIOS.

I can only confirm that. I installed a more recent system on the same
hardware, rebuilt a kernel from the same config file, and now it boots
OK. So it's not related to the hardware. It has to be a compilation-time
issue.

-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Thu, 21 Dec 2006 08:43:26 +0530, Vivek Goyal wrote:
> On Thu, Dec 21, 2006 at 02:13:54PM +0100, Jean Delvare wrote:
> > On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> > > Looks like it might be a tool chain issue. I took Jean's config file and
> > > built my own kernel and I am able to boot the kernel. But I can't boot
> > > his bzImage. I observed the same behaviour as jean is experiencing. It jumps
> > > back to BIOS.
> > 
> > I can only confirm that. I installed a more recent system on the same
> > hardware, rebuilt a kernel from the same config file, and now it boots
> > OK. So it's not related to the hardware. It has to be a compilation-time
> > issue.
> 
> Looks like you have already trashed your setup. If not, is it possible to

No, of course I didn't. I installed the new system on a different hard
disk drive.

> upload the output of "objdump -D arch/i386/boot/setup.o"? This will give
> some info regarding what assembler is doing.

Here you go:
http://jdelvare.pck.nerim.net/linux/relocatable-bug/setup.asm

-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

On Thu, 21 Dec 2006 09:10:29 +0530, Vivek Goyal wrote:
> Ok. so indirect jump seems to be having problem. On my machine disassembly
> of setup.o show following.
> 
> ff a6 14 02 00 00       jmp    *0x214(%esi)
> 
> This seems to be fine as 0x14 is the offset of code32_start, and 
> ((DELTA_INITSEG) << 4) is 0x200. How does it look like on your machine?

    1110:	ff a6 14 02 00 00    	jmp    *0x214(%esi)

So exactly the same.

-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Alexander van Heukelum]

On Thu, 21 Dec 2006 14:59:22 +0100, "Jean Delvare" <khali@linux-fr.org>
said:
> Hi Vivek,
> 
> On Thu, 21 Dec 2006 08:43:26 +0530, Vivek Goyal wrote:
> > On Thu, Dec 21, 2006 at 02:13:54PM +0100, Jean Delvare wrote:
> > > On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> > > > Looks like it might be a tool chain issue. I took Jean's config file and
> > > > built my own kernel and I am able to boot the kernel. But I can't boot
> > > > his bzImage. I observed the same behaviour as jean is experiencing. It jumps
> > > > back to BIOS.
> > > 
> > > I can only confirm that. I installed a more recent system on the same
> > > hardware, rebuilt a kernel from the same config file, and now it boots
> > > OK. So it's not related to the hardware. It has to be a compilation-time
> > > issue.
> > 
> > Looks like you have already trashed your setup. If not, is it possible to
> 
> No, of course I didn't. I installed the new system on a different hard
> disk drive.
> 
> > upload the output of "objdump -D arch/i386/boot/setup.o"? This will give
> > some info regarding what assembler is doing.
> 
> Here you go:
> http://jdelvare.pck.nerim.net/linux/relocatable-bug/setup.asm

Hi,

Hmm. taking a peek at the bzImage there...

00001d80  41 00 56 45 53 41 00 56  69 64 65 6f 20 61 64 61 
|A.VESA.Video ada|
00001d90  70 74 65 72 3a 20 00 00  00 b8 00 00 55 aa 5a 5a  |pter:
......U.ZZ|
00001da0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
00001e00  4e 35 13 00 1f 8b 08 00  23 a4 89 45 02 03 b4 fd 
|N5......#..E....|
          -- -- -- -- ^^ ^^ ^^

This is the end of the realmode kernel, and it should be followed by the
32-bit code that is to be executed at (normally) 0x100000, right? This
is however not the case here. Where did arch/i386/boot/compressed/head.S
go then? What is the significance of this value 0x0013354e? It is in
fact
exactly the size of the compressed kernel image.

I have no idea what went wrong, but it went wrong in the build process
of the bzImage.

Hope this helps,
    Alexander

> -- 
> Jean Delvare
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - Send your email first class

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Thu, Dec 21, 2006 at 06:45:57PM +0100, Alexander van Heukelum wrote:
> Hi,
> 
> Hmm. taking a peek at the bzImage there...
> 
> 00001d80  41 00 56 45 53 41 00 56  69 64 65 6f 20 61 64 61
> |A.VESA.Video ada|
> 00001d90  70 74 65 72 3a 20 00 00  00 b8 00 00 55 aa 5a 5a  |pter:
> ......U.ZZ|
> 00001da0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> |................|
> *
> 00001e00  4e 35 13 00 1f 8b 08 00  23 a4 89 45 02 03 b4 fd
> |N5......#..E....|
>           -- -- -- -- ^^ ^^ ^^
> 
> This is the end of the realmode kernel, and it should be followed by the
> 32-bit code that is to be executed at (normally) 0x100000, right? This
> is however not the case here. Where did arch/i386/boot/compressed/head.S
> go then? What is the significance of this value 0x0013354e? It is in
> fact
> exactly the size of the compressed kernel image.
> 
> I have no idea what went wrong, but it went wrong in the build process
> of the bzImage.
> 

Hi Alexander,

Excellent observation. I did an "od -Ax -tx1" on bzImage built by me and
I can see the right startup_32() code bytes at the end of real mode code.

001d20 74 65 72 3a 20 00 00 00 b8 00 00 55 aa 5a 5a 00
001d30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
001e00 fc fa b8 18 00 00 00 8e d8 8e c0 8e e0 8e e8 8e
       ^^^^^^^^^^^
Following is the disassembly of startup_32() in
arch/386/boot/compressed/head.S

00000000 <startup_32>:
   0:   fc                      cld
   1:   fa                      cli
   2:   b8 18 00 00 00          mov    $0x18,%eax

So I can see 0x18b8fafc being rightly placed immediately after real
mode code (setup.S). But that does not seem to be the case with Jean's
bzImage.

The only place where size of compressed kernel (vmlinux.bin.gz) is placed
is piggy.o. Look at arch/i386/boot/compressed/vmlinux.scr. Here we put
the size of vmlinux.bin.gz in .data.compressed section before we put
actual vmlinux.bin.gz in this section.

Does that mean that somehow .data.compressed section was placed before
.text.head section? But that would be contarary to what
arch/i386/boot/compressed/vmlinux.lds instructs to linker.

At the same time I tried to find the pattern 0x18b8fafc in Jean's bzImage
but I can't find that. Does that mean that arch/i386/boot/compressed/head.S
was never compiled  and linked? 

Jean, can you please upload some more files. Should give some more idea
about what happened in your environment.

arch/i386/boot/vmlinux.bin
arch/i386/boot/compressed/piggy.o
arch/i386/boot/compressed/head.o

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Fri, 22 Dec 2006 02:14:08 +0530, Vivek Goyal wrote:
> Jean, can you please upload some more files. Should give some more idea
> about what happened in your environment.
> 
> arch/i386/boot/vmlinux.bin
> arch/i386/boot/compressed/piggy.o
> arch/i386/boot/compressed/head.o

Sure, here they are:
http://jdelvare.pck.nerim.net/linux/relocatable-bug/

Thanks,
-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Fri, Dec 22, 2006 at 09:08:06AM +0100, Jean Delvare wrote:
> Hi Vivek,
> 
> On Fri, 22 Dec 2006 02:14:08 +0530, Vivek Goyal wrote:
> > Jean, can you please upload some more files. Should give some more idea
> > about what happened in your environment.
> >
> > arch/i386/boot/vmlinux.bin
> > arch/i386/boot/compressed/piggy.o
> > arch/i386/boot/compressed/head.o
> 
> Sure, here they are:
> http://jdelvare.pck.nerim.net/linux/relocatable-bug/
> 

Thanks Jean. Your compressed/head.o looks fine.

Disassembly of section .text.head:

00000000 <startup_32>:
   0:   fc                      cld
   1:   fa                      cli
   2:   b8 18 00 00 00          mov    $0x18,%eax

compressed/piggy.o also looks fine. In this relocatable object,
compressed kernel size is present at office 0x34.

000000 464c457f 00010101 00000000 00000000
000010 00030001 00000001 00000000 00000000
000020 0013358c 00000000 00000034 00280000
000030 00020005 00133526 00088b1f 458a914d
                ^^^^^^^

But vmlinux.bin is not good. It should have contained startup_32() code
bytes from compressed/head.S but it seems to basically cotain piggy.o data
at the beginning. Instead it should have had .text.head section in the
beginning.

000000 00133526 00088b1f 458a914d fdb40302
       ^^^^^^^ (compressed kernel size. Same as piggy.o)

boot/vmlinux.bin is made after stripping boot/compressed/vmlinux. And 
boot/compressed/vmlinux is made with the linking of head.o, misc.o and
piggy.o. So either objcopy did something wrong or linker itself did not
generate a proper compressed/vmlinux. 

Can you please also upload boot/compressed/vmlinux.

Another odd thing is that "file vmlinux.bin" shows following.

vmlinux.bin: Sendmail frozen configuration  - version \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003

I am not sure what does it mean. I had expected it to be a data blob.

"vmlinux.bin: data"

Can you please also compile the kernel in verbose mode "make V=1" and
upload the output. just wanted to make sure Makefiles are being
interpreted properly.

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
> Another odd thing is that "file vmlinux.bin" shows following.
> 
> vmlinux.bin: Sendmail frozen configuration  - version \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003
> 
> I am not sure what does it mean. I had expected it to be a data blob.
> 
> "vmlinux.bin: data"

The file command uses heuristics to attempt to identify files. Here a
random sequence of bytes was simply misinterpreted as something
completely different. You can tell from the version string which is
totally broken. So, "file" could be improved to avoid this false
positive, but that's about it.

Now, what's still relevant is that my vmlinux.bin starts with a
binary sequence which differs from all other vmlinux.bin files around.
So it's a hint that it is corrupted, although a deeper analysis will be
required to figure out how and why.

-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Jean Delvare <khali@linux-fr.org> writes:

> Hi Vivek,
>
> On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
>> Another odd thing is that "file vmlinux.bin" shows following.
>> 
>> vmlinux.bin: Sendmail frozen configuration - version
> \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003
>> 
>> I am not sure what does it mean. I had expected it to be a data blob.
>> 
>> "vmlinux.bin: data"
>
> The file command uses heuristics to attempt to identify files. Here a
> random sequence of bytes was simply misinterpreted as something
> completely different. You can tell from the version string which is
> totally broken. So, "file" could be improved to avoid this false
> positive, but that's about it.
>
> Now, what's still relevant is that my vmlinux.bin starts with a
> binary sequence which differs from all other vmlinux.bin files around.
> So it's a hint that it is corrupted, although a deeper analysis will be
> required to figure out how and why.

A simple analysis says vmlinux.bin is created by the linker.  So we
can probably look at why vmlinux.bin gets generated strangely.

I know I touched that path a little bit in my patch.

Eric

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Segher Boessenkool]

> Thanks Jean. Your compressed/head.o looks fine.

No it doesn't -- the .text.head section doesn't have
the ALLOC attribute set.  The section then ends up not
being assigned to an output segment (during the linking
of vmlinux) and all hell breaks loose.  The linker gives
you a warning about this btw.

Jean, how old is your binutils?
Since 2.15 at least this should be set automatically
on sections named .text.<whatever> .

It wouldn't hurt to specify it by hand in the source
code of course -- change

.section ".text.head"

to

.section ".text.head","ax",@progbits

in compressed/head.S .


Segher

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Segher,

On Tue, 26 Dec 2006 13:43:31 +0100, Segher Boessenkool wrote:
> > Thanks Jean. Your compressed/head.o looks fine.
> 
> No it doesn't -- the .text.head section doesn't have
> the ALLOC attribute set.  The section then ends up not
> being assigned to an output segment (during the linking
> of vmlinux) and all hell breaks loose.  The linker gives
> you a warning about this btw.

I didn't notice any warning, but maybe I just missed it.

> Jean, how old is your binutils?

2.14.90.0.6

> Since 2.15 at least this should be set automatically
> on sections named .text.<whatever> .
> 
> It wouldn't hurt to specify it by hand in the source
> code of course -- change
> 
> .section ".text.head"
> 
> to
> 
> .section ".text.head","ax",@progbits
> 
> in compressed/head.S .

I don't have access to this test system at the moment, I'll check, test
and report back once I have access again.

Thanks,
-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Tue, Dec 26, 2006 at 01:43:31PM +0100, Segher Boessenkool wrote:
> >Thanks Jean. Your compressed/head.o looks fine.
> 
> No it doesn't -- the .text.head section doesn't have
> the ALLOC attribute set.  The section then ends up not
> being assigned to an output segment (during the linking
> of vmlinux) and all hell breaks loose.  The linker gives
> you a warning about this btw.
> 

Thanks Segher. You are right. I did not notice that.

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 000044 00  AX  0   0  4
  [ 2] .rel.text         REL             00000000 0005c8 000040 08      8   1  4
  [ 3] .data             PROGBITS        00000000 000078 000000 00  WA  0   0  4
  [ 4] .bss              NOBITS          00000000 000078 001000 00  WA  0   0  4
  [ 5] .text.head        PROGBITS        00000000 000078 00006e 00      0   0  1

.text.head is not type AX so it will be left out from the linked output.
This reminds me that I have put another patch in kernel/head.S creating
a new section .text.head. I think I shall have to put a patch there too
to make it work with older binutils.

Thanks
Vivek

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Segher Boessenkool]

> .text.head is not type AX so it will be left out from the linked 
> output.

No, it does get added, but the section is not added to
any segment, so a) it ends up near the end of the address
map instead of being first thing, and b) it won't be loaded
at run time.

> This reminds me that I have put another patch in kernel/head.S creating
> a new section .text.head. I think I shall have to put a patch there too
> to make it work with older binutils.

Yeah.  Current stuff works with 2.15, which is three years
old, but it doesn't hurt supporting older toolchains where
possible.


Segher

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

Sorry for the delay, I'm just back from vacation. I tried it all again
with 2.6.20-rc3 just in case, but the problem I've hit is still present.

On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
> Can you please also upload boot/compressed/vmlinux.

I've shared the whole build tree so that you can peek at files without
waiting for me to upload them. It is temporarily available at:
  http://jdelvare.pck.nerim.net/linux/relocatable-bug/
Hidden files are there too, just not listed.

Thanks,
-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Vivek Goyal]

On Mon, Jan 01, 2007 at 10:39:13PM +0100, Jean Delvare wrote:
> Hi Vivek,
> 
> Sorry for the delay, I'm just back from vacation. I tried it all again
> with 2.6.20-rc3 just in case, but the problem I've hit is still present.
> 

Hi Jean,

Problem in not fixed yet in -rc3. So testing -rc3 will not help.

Segher had suggested to use .section command to specifically mark
.text.head section as AX (allocatable and executable) to solve the
problem.

Can you please try the attached patch to see if it solves your
problem.

Thanks
Vivek


Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 arch/i386/boot/compressed/head.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN arch/i386/boot/compressed/head.S~jean-reboot-issue-fix arch/i386/boot/compressed/head.S
--- linux-2.6.20-rc2-reloc/arch/i386/boot/compressed/head.S~jean-reboot-issue-fix	2007-01-02 09:54:56.000000000 +0530
+++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S	2007-01-02 09:57:46.000000000 +0530
@@ -28,7 +28,7 @@
 #include <asm/page.h>
 #include <asm/boot.h>
 
-.section ".text.head"
+.section ".text.head","ax",@progbits
 	.globl startup_32
 
 startup_32:
_

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Tue, 2 Jan 2007 11:41:47 +0530, Vivek Goyal wrote:
> Segher had suggested to use .section command to specifically mark
> .text.head section as AX (allocatable and executable) to solve the
> problem.
> 
> Can you please try the attached patch to see if it solves your
> problem.
> 
> Thanks
> Vivek
> 
> 
> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
> ---
> 
>  arch/i386/boot/compressed/head.S |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN arch/i386/boot/compressed/head.S~jean-reboot-issue-fix arch/i386/boot/compressed/head.S
> --- linux-2.6.20-rc2-reloc/arch/i386/boot/compressed/head.S~jean-reboot-issue-fix	2007-01-02 09:54:56.000000000 +0530
> +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S	2007-01-02 09:57:46.000000000 +0530
> @@ -28,7 +28,7 @@
>  #include <asm/page.h>
>  #include <asm/boot.h>
>  
> -.section ".text.head"
> +.section ".text.head","ax",@progbits
>  	.globl startup_32
>  
>  startup_32:
> _

Yes! The patch above fixes the problem, and doesn't appear to cause any
regression on my other systems. Thanks Vivek and Segher!

I guess we now want to push this patch upstream rather sooner than
later, and at any rate before 2.6.20 final is released. Eric, can you
please review the patch, and if it looks OK to you, sign it and send it
to Linus?

Thanks,
-- 
Jean Delvare

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Segher Boessenkool]

>> Segher had suggested to use .section command to specifically mark
>> .text.head section as AX (allocatable and executable) to solve the
>> problem.

Great to hear it works in real life too.

Here, have a From: line (or how should this patch history be
encoded?) :-)

From: Segher Boessenkool <segher@kernel.crashing.org>
>> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
>> ---
>>
>>  arch/i386/boot/compressed/head.S |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff -puN arch/i386/boot/compressed/head.S~jean-reboot-issue-fix  
>> arch/i386/boot/compressed/head.S
>> ---  
>> linux-2.6.20-rc2-reloc/arch/i386/boot/compressed/head.S~jean-reboot- 
>> issue-fix	2007-01-02 09:54:56.000000000 +0530
>> +++  
>> linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S	2007-01 
>> -02 09:57:46.000000000 +0530
>> @@ -28,7 +28,7 @@
>>  #include <asm/page.h>
>>  #include <asm/boot.h>
>>
>> -.section ".text.head"
>> +.section ".text.head","ax",@progbits
>>  	.globl startup_32
>>
>>  startup_32: