Jean Delvare <[email protected]> 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
On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
> Jean Delvare <[email protected]> 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
Vivek Goyal <[email protected]> writes:
> On Thu, Dec 21, 2006 at 03:32:33AM -0700, Eric W. Biederman wrote:
>> Jean Delvare <[email protected]> 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
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
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
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
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
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
On Thu, 21 Dec 2006 14:59:22 +0100, "Jean Delvare" <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Alexander van Heukelum
[email protected]
--
http://www.fastmail.fm - Send your email first class
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
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
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
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
Jean Delvare <[email protected]> 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
> 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
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
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
> .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
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
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 <[email protected]>
---
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:
_
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 <[email protected]>
> ---
>
> 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
>> 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 <[email protected]>
>> Signed-off-by: Vivek Goyal <[email protected]>
>> ---
>>
>> 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: