Re: Patch "i386: Relocatable kernel support" causes instant reboot
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.0 +0530 +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S 2007-01 -02 09:57:46.0 +0530 @@ -28,7 +28,7 @@ #include #include -.section ".text.head" +.section ".text.head","ax",@progbits .globl startup_32 startup_32: - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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.0 +0530 > +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S > 2007-01-02 09:57:46.0 +0530 > @@ -28,7 +28,7 @@ > #include > #include > > -.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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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.0 +0530 +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S 2007-01-02 09:57:46.0 +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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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.0 +0530 +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S 2007-01 -02 09:57:46.0 +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: - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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.0 +0530 +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S 2007-01-02 09:57:46.0 +0530 @@ -28,7 +28,7 @@ #include #include -.section ".text.head" +.section ".text.head","ax",@progbits .globl startup_32 startup_32: _ - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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.0 +0530 +++ linux-2.6.20-rc2-reloc-root/arch/i386/boot/compressed/head.S 2007-01-02 09:57:46.0 +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: _ - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
.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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 44 00 AX 0 0 4 [ 2] .rel.text REL 0005c8 40 08 8 1 4 [ 3] .data PROGBITS 78 00 00 WA 0 0 4 [ 4] .bss NOBITS 78 001000 00 WA 0 0 4 [ 5] .text.headPROGBITS 78 6e 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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. . > > 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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. . 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 44 00 AX 0 0 4 [ 2] .rel.text REL 0005c8 40 08 8 1 4 [ 3] .data PROGBITS 78 00 00 WA 0 0 4 [ 4] .bss NOBITS 78 001000 00 WA 0 0 4 [ 5] .text.headPROGBITS 78 6e 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
.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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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: : 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. 00 464c457f 00010101 10 00030001 0001 20 0013358c 0034 0028 30 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. 00 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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: 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. 00 464c457f 00010101 10 00030001 0001 20 0013358c 0034 0028 30 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. 00 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
On Thu, Dec 21, 2006 at 06:45:57PM +0100, Alexander van Heukelum wrote: > Hi, > > Hmm. taking a peek at the bzImage there... > > 1d80 41 00 56 45 53 41 00 56 69 64 65 6f 20 61 64 61 > |A.VESA.Video ada| > 1d90 70 74 65 72 3a 20 00 00 00 b8 00 00 55 aa 5a 5a |pter: > ..U.ZZ| > 1da0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > || > * > 1e00 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) 0x10, 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 : 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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... 1d80 41 00 56 45 53 41 00 56 69 64 65 6f 20 61 64 61 |A.VESA.Video ada| 1d90 70 74 65 72 3a 20 00 00 00 b8 00 00 55 aa 5a 5a |pter: ..U.ZZ| 1da0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1e00 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) 0x10, 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 > > 0x10 > > - # 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, 0x # loop forever if it isn't > > + cmpl %eax, 0x0010 > > + 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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: jmp10b > > 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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: > calldefault_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 > lidtidt_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) > lgdtgdt_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 > 0x10 > - # 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, 0x # loop forever if it isn't > + cmpl %eax, 0x0010 > + 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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: calldefault_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 lidtidt_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) lgdtgdt_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 0x10 - # 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, 0x
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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: jmp10b lidtidt_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: jmp11b # 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: jmp12b movl $(__BOOT_DS), %eax movl %eax, %ds movl %eax, %es @@ -869,12 +872,14 @@ startup_32: movl %eax, %gs movl %eax, %ss +13: jmp13b xorl %eax, %eax 1: incl %eax # check that A20 really IS enabled movl %eax, 0x # loop forever if it isn't cmpl %eax, 0x0010 je 1b +14: jmp14b # Jump to the 32bit entry point jmpl *(code32_start - start + (DELTA_INITSEG << 4))(%esi) .code16 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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=0x10 (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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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=0x10 (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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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: jmp10b lidtidt_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: jmp11b # 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: jmp12b movl $(__BOOT_DS), %eax movl %eax, %ds movl %eax, %es @@ -869,12 +872,14 @@ startup_32: movl %eax, %gs movl %eax, %ss +13: jmp13b xorl %eax, %eax 1: incl %eax # check that A20 really IS enabled movl %eax, 0x # loop forever if it isn't cmpl %eax, 0x0010 je 1b +14: jmp14b # Jump to the 32bit entry point jmpl *(code32_start - start + (DELTA_INITSEG 4))(%esi) .code16 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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: calldefault_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 lidtidt_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) lgdtgdt_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 0x10 - # 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, 0x # loop forever if it isn't + cmpl %eax, 0x0010 + je 1b + + # Jump to the 32bit entry point + jmpl *(code32_start
Re: Patch i386: Relocatable kernel support causes instant reboot
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: calldefault_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 lidtidt_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) lgdtgdt_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 0x10 - # 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, 0x # loop forever if it isn't + cmpl %eax, 0x0010 + 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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: jmp10b 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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 0x10 - # 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, 0x # loop forever if it isn't + cmpl %eax, 0x0010 + 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
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... 1d80 41 00 56 45 53 41 00 56 69 64 65 6f 20 61 64 61 |A.VESA.Video ada| 1d90 70 74 65 72 3a 20 00 00 00 b8 00 00 55 aa 5a 5a |pter: ..U.ZZ| 1da0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1e00 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) 0x10, 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
On Thu, Dec 21, 2006 at 06:45:57PM +0100, Alexander van Heukelum wrote: Hi, Hmm. taking a peek at the bzImage there... 1d80 41 00 56 45 53 41 00 56 69 64 65 6f 20 61 64 61 |A.VESA.Video ada| 1d90 70 74 65 72 3a 20 00 00 00 b8 00 00 55 aa 5a 5a |pter: ..U.ZZ| 1da0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1e00 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) 0x10, 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 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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
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 - 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/
Re: Patch "i386: Relocatable kernel support" causes instant reboot
Jean Delvare <[EMAIL PROTECTED]> 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. */ - To unsubscribe from this list: send the line "unsubscribe
Re: Patch "i386: Relocatable kernel support" causes instant reboot
Jean Delvare <[EMAIL PROTECTED]> 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
Jean Delvare [EMAIL PROTECTED] 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 - 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/
Re: Patch i386: Relocatable kernel support causes instant reboot
Jean Delvare [EMAIL PROTECTED] 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. */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More
Re: Patch i386: Relocatable kernel support causes instant reboot
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 - 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/
