* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-30 15:12 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-30 15:12 UTC (permalink / raw) To: Andi Kleen, Andrew Morton Cc: Jurriaan, Helge Hafting, linux-kernel, Horms, Kexec Mailing List Currently because vmlinux does not reflect that the kernel is relocatable we still have to support CONFIG_PHYSICAL_START. So this patch adds a small c program to do what we cannot do with a linker script set the elf header type to ET_DYN. Since last time I have fixed the type to be in my code ET_DYN (oops), and verified this works with kexec. I realized while testing that we don't have anyway of identifying a kernel vmlinux as linux so we probably want to add an ELF note but that will be another patch. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86_64/Kconfig | 4 +++ arch/x86_64/Makefile | 10 +++++++ scripts/Makefile | 11 ++++--- scripts/mketrel.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 5 deletions(-) create mode 100644 scripts/mketrel.c diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index b00adb9..95949c3 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ELF_RELOCATABLE + bool + default y + source "init/Kconfig" diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index a81a84a..7c0434c 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -125,6 +125,16 @@ define archhelp echo ' isoimage - Create a boot CD-ROM image' endef +ifeq ($(CONFIG_RELOCATABLE),y) +define cmd_vmlinux__ + $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ + -T $(vmlinux-lds) $(vmlinux-init) \ + --start-group $(vmlinux-main) --end-group \ + $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \ + && scripts/mketrel $@ +endef +endif + CLEAN_FILES += arch/$(ARCH)/boot/fdimage \ arch/$(ARCH)/boot/image.iso \ arch/$(ARCH)/boot/mtools.conf diff --git a/scripts/Makefile b/scripts/Makefile index 1c73c5a..ddba550 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -7,11 +7,12 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables -hostprogs-$(CONFIG_KALLSYMS) += kallsyms -hostprogs-$(CONFIG_LOGO) += pnmtologo -hostprogs-$(CONFIG_VT) += conmakehash -hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash -hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_KALLSYMS) += kallsyms +hostprogs-$(CONFIG_LOGO) += pnmtologo +hostprogs-$(CONFIG_VT) += conmakehash +hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash +hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel always := $(hostprogs-y) $(hostprogs-m) diff --git a/scripts/mketrel.c b/scripts/mketrel.c new file mode 100644 index 0000000..aa0408a --- /dev/null +++ b/scripts/mketrel.c @@ -0,0 +1,70 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <unistd.h> +#include <elf.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdarg.h> +#include <stdlib.h> + +static int fd; +unsigned char e_ident[EI_NIDENT]; + +void die(const char * str, ...) +{ + va_list args; + va_start(args, str); + vfprintf(stderr, str, args); + fputc('\n', stderr); + exit(1); +} + +void file_open(const char *name) +{ + if ((fd = open(name, O_RDWR, 0)) < 0) + die("Unable to open `%s': %m", name); +} + +static void mketrel(void) +{ + unsigned char e_type[2]; + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) + die("Cannot read ELF header: %s\n", strerror(errno)); + + if (memcmp(e_ident, ELFMAG, 4) != 0) + die("No ELF magic\n"); + + if ((e_ident[EI_CLASS] != ELFCLASS64) && + (e_ident[EI_CLASS] != ELFCLASS32)) + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); + + if ((e_ident[EI_DATA] != ELFDATA2LSB) && + (e_ident[EI_DATA] != ELFDATA2MSB)) + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); + + if (e_ident[EI_VERSION] != EV_CURRENT) + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); + + if (e_ident[EI_DATA] == ELFDATA2LSB) { + e_type[0] = ET_DYN & 0xff; + e_type[1] = ET_DYN >> 8; + } else { + e_type[1] = ET_DYN & 0xff; + e_type[0] = ET_DYN >> 8; + } + + if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type)) + die("Cannot write ELF type: %s\n", strerror(errno)); +} + +int main(int argc, char **argv) +{ + if (argc != 2) + die("Usage: mketrel: vmlinux"); + file_open(argv[1]); + mketrel(); + close(fd); + return 0; +} -- 1.5.1.1.181.g2de0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-30 15:12 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-30 15:12 UTC (permalink / raw) To: Andi Kleen, Andrew Morton Cc: Helge Hafting, Horms, Kexec Mailing List, Jurriaan, linux-kernel Currently because vmlinux does not reflect that the kernel is relocatable we still have to support CONFIG_PHYSICAL_START. So this patch adds a small c program to do what we cannot do with a linker script set the elf header type to ET_DYN. Since last time I have fixed the type to be in my code ET_DYN (oops), and verified this works with kexec. I realized while testing that we don't have anyway of identifying a kernel vmlinux as linux so we probably want to add an ELF note but that will be another patch. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86_64/Kconfig | 4 +++ arch/x86_64/Makefile | 10 +++++++ scripts/Makefile | 11 ++++--- scripts/mketrel.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 5 deletions(-) create mode 100644 scripts/mketrel.c diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index b00adb9..95949c3 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ELF_RELOCATABLE + bool + default y + source "init/Kconfig" diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index a81a84a..7c0434c 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -125,6 +125,16 @@ define archhelp echo ' isoimage - Create a boot CD-ROM image' endef +ifeq ($(CONFIG_RELOCATABLE),y) +define cmd_vmlinux__ + $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ + -T $(vmlinux-lds) $(vmlinux-init) \ + --start-group $(vmlinux-main) --end-group \ + $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \ + && scripts/mketrel $@ +endef +endif + CLEAN_FILES += arch/$(ARCH)/boot/fdimage \ arch/$(ARCH)/boot/image.iso \ arch/$(ARCH)/boot/mtools.conf diff --git a/scripts/Makefile b/scripts/Makefile index 1c73c5a..ddba550 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -7,11 +7,12 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables -hostprogs-$(CONFIG_KALLSYMS) += kallsyms -hostprogs-$(CONFIG_LOGO) += pnmtologo -hostprogs-$(CONFIG_VT) += conmakehash -hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash -hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_KALLSYMS) += kallsyms +hostprogs-$(CONFIG_LOGO) += pnmtologo +hostprogs-$(CONFIG_VT) += conmakehash +hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash +hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel always := $(hostprogs-y) $(hostprogs-m) diff --git a/scripts/mketrel.c b/scripts/mketrel.c new file mode 100644 index 0000000..aa0408a --- /dev/null +++ b/scripts/mketrel.c @@ -0,0 +1,70 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <unistd.h> +#include <elf.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdarg.h> +#include <stdlib.h> + +static int fd; +unsigned char e_ident[EI_NIDENT]; + +void die(const char * str, ...) +{ + va_list args; + va_start(args, str); + vfprintf(stderr, str, args); + fputc('\n', stderr); + exit(1); +} + +void file_open(const char *name) +{ + if ((fd = open(name, O_RDWR, 0)) < 0) + die("Unable to open `%s': %m", name); +} + +static void mketrel(void) +{ + unsigned char e_type[2]; + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) + die("Cannot read ELF header: %s\n", strerror(errno)); + + if (memcmp(e_ident, ELFMAG, 4) != 0) + die("No ELF magic\n"); + + if ((e_ident[EI_CLASS] != ELFCLASS64) && + (e_ident[EI_CLASS] != ELFCLASS32)) + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); + + if ((e_ident[EI_DATA] != ELFDATA2LSB) && + (e_ident[EI_DATA] != ELFDATA2MSB)) + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); + + if (e_ident[EI_VERSION] != EV_CURRENT) + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); + + if (e_ident[EI_DATA] == ELFDATA2LSB) { + e_type[0] = ET_DYN & 0xff; + e_type[1] = ET_DYN >> 8; + } else { + e_type[1] = ET_DYN & 0xff; + e_type[0] = ET_DYN >> 8; + } + + if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type)) + die("Cannot write ELF type: %s\n", strerror(errno)); +} + +int main(int argc, char **argv) +{ + if (argc != 2) + die("Usage: mketrel: vmlinux"); + file_open(argv[1]); + mketrel(); + close(fd); + return 0; +} -- 1.5.1.1.181.g2de0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-04-30 15:12 ` Eric W. Biederman @ 2007-04-30 15:17 ` Andi Kleen -1 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-04-30 15:17 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel, Horms, Kexec Mailing List On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > > Currently because vmlinux does not reflect that the kernel is relocatable > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > c program to do what we cannot do with a linker script set the elf header > type to ET_DYN. > > Since last time I have fixed the type to be in my code ET_DYN (oops), > and verified this works with kexec. I realized while testing that we > don't have anyway of identifying a kernel vmlinux as linux so we > probably want to add an ELF note but that will be another patch. The patch is ok for me, but does it pass Vivek's usual testing? -Andi ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-30 15:17 ` Andi Kleen 0 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-04-30 15:17 UTC (permalink / raw) To: Eric W. Biederman Cc: Kexec Mailing List, Jurriaan, linux-kernel, Helge Hafting, Horms, Andrew Morton On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > > Currently because vmlinux does not reflect that the kernel is relocatable > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > c program to do what we cannot do with a linker script set the elf header > type to ET_DYN. > > Since last time I have fixed the type to be in my code ET_DYN (oops), > and verified this works with kexec. I realized while testing that we > don't have anyway of identifying a kernel vmlinux as linux so we > probably want to add an ELF note but that will be another patch. The patch is ok for me, but does it pass Vivek's usual testing? -Andi _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-04-30 15:17 ` Andi Kleen @ 2007-05-01 3:55 ` Vivek Goyal -1 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 3:55 UTC (permalink / raw) To: Andi Kleen Cc: Eric W. Biederman, Kexec Mailing List, Jurriaan, linux-kernel, Helge Hafting, Horms, Andrew Morton On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > > > > Currently because vmlinux does not reflect that the kernel is relocatable > > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > > c program to do what we cannot do with a linker script set the elf header > > type to ET_DYN. > > > > Since last time I have fixed the type to be in my code ET_DYN (oops), > > and verified this works with kexec. I realized while testing that we > > don't have anyway of identifying a kernel vmlinux as linux so we > > probably want to add an ELF note but that will be another patch. > > The patch is ok for me, but does it pass Vivek's usual testing? I am facing one issue with this patch. gdb can not analyze the resulting kernel core file. Looks like gdb treats vmlinux differently if ELF header type is "ET_DYN". It reads the symbol values incorrectly. For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but gdb somehow things that it is 0xffffffff008aaebf. Looks like it is performing some relocation. I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 3:55 ` Vivek Goyal 0 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 3:55 UTC (permalink / raw) To: Andi Kleen Cc: Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Eric W. Biederman, Andrew Morton On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > > > > Currently because vmlinux does not reflect that the kernel is relocatable > > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > > c program to do what we cannot do with a linker script set the elf header > > type to ET_DYN. > > > > Since last time I have fixed the type to be in my code ET_DYN (oops), > > and verified this works with kexec. I realized while testing that we > > don't have anyway of identifying a kernel vmlinux as linux so we > > probably want to add an ELF note but that will be another patch. > > The patch is ok for me, but does it pass Vivek's usual testing? I am facing one issue with this patch. gdb can not analyze the resulting kernel core file. Looks like gdb treats vmlinux differently if ELF header type is "ET_DYN". It reads the symbol values incorrectly. For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but gdb somehow things that it is 0xffffffff008aaebf. Looks like it is performing some relocation. I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 3:55 ` Vivek Goyal @ 2007-05-01 4:20 ` Eric W. Biederman -1 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 4:20 UTC (permalink / raw) To: vgoyal Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton Vivek Goyal <vgoyal@in.ibm.com> writes: > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: >> > >> > Currently because vmlinux does not reflect that the kernel is relocatable >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small >> > c program to do what we cannot do with a linker script set the elf header >> > type to ET_DYN. >> > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), >> > and verified this works with kexec. I realized while testing that we >> > don't have anyway of identifying a kernel vmlinux as linux so we >> > probably want to add an ELF note but that will be another patch. >> >> The patch is ok for me, but does it pass Vivek's usual testing? > > I am facing one issue with this patch. gdb can not analyze the > resulting kernel core file. Looks like gdb treats vmlinux differently if > ELF header type is "ET_DYN". It reads the symbol values incorrectly. Weird. > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is > performing some relocation. > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Does it take a kernel core file to reproduce this problem? Or can you just open up gdb on a vmlinux and look at the symbol address? At least without a core file it is working on with gdb 6.4. Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 4:20 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 4:20 UTC (permalink / raw) To: vgoyal Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan, Helge Hafting, Horms, Andrew Morton Vivek Goyal <vgoyal@in.ibm.com> writes: > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: >> > >> > Currently because vmlinux does not reflect that the kernel is relocatable >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small >> > c program to do what we cannot do with a linker script set the elf header >> > type to ET_DYN. >> > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), >> > and verified this works with kexec. I realized while testing that we >> > don't have anyway of identifying a kernel vmlinux as linux so we >> > probably want to add an ELF note but that will be another patch. >> >> The patch is ok for me, but does it pass Vivek's usual testing? > > I am facing one issue with this patch. gdb can not analyze the > resulting kernel core file. Looks like gdb treats vmlinux differently if > ELF header type is "ET_DYN". It reads the symbol values incorrectly. Weird. > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is > performing some relocation. > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Does it take a kernel core file to reproduce this problem? Or can you just open up gdb on a vmlinux and look at the symbol address? At least without a core file it is working on with gdb 6.4. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 4:20 ` Eric W. Biederman @ 2007-05-01 5:06 ` Vivek Goyal -1 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 5:06 UTC (permalink / raw) To: Eric W. Biederman Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton, vgoyal On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > >> > > >> > Currently because vmlinux does not reflect that the kernel is relocatable > >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > >> > c program to do what we cannot do with a linker script set the elf header > >> > type to ET_DYN. > >> > > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), > >> > and verified this works with kexec. I realized while testing that we > >> > don't have anyway of identifying a kernel vmlinux as linux so we > >> > probably want to add an ELF note but that will be another patch. > >> > >> The patch is ok for me, but does it pass Vivek's usual testing? > > > > I am facing one issue with this patch. gdb can not analyze the > > resulting kernel core file. Looks like gdb treats vmlinux differently if > > ELF header type is "ET_DYN". It reads the symbol values incorrectly. > > Weird. > > > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but > > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is > > performing some relocation. > > > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). > > Does it take a kernel core file to reproduce this problem? > Or can you just open up gdb on a vmlinux and look at the symbol > address? It takes a core file to reproduce the problem. Without core file gdb can get right symbol addresses. > > At least without a core file it is working on with gdb 6.4. > This seems to be a problem with gdb 6.5. I transferred the dump to a different machine having GNU gdb 6.4, and it works fine there. Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 5:06 ` Vivek Goyal 0 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 5:06 UTC (permalink / raw) To: Eric W. Biederman Cc: linux-kernel, vgoyal, Kexec Mailing List, Andi Kleen, Jurriaan, Helge Hafting, Horms, Andrew Morton On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > >> > > >> > Currently because vmlinux does not reflect that the kernel is relocatable > >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > >> > c program to do what we cannot do with a linker script set the elf header > >> > type to ET_DYN. > >> > > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), > >> > and verified this works with kexec. I realized while testing that we > >> > don't have anyway of identifying a kernel vmlinux as linux so we > >> > probably want to add an ELF note but that will be another patch. > >> > >> The patch is ok for me, but does it pass Vivek's usual testing? > > > > I am facing one issue with this patch. gdb can not analyze the > > resulting kernel core file. Looks like gdb treats vmlinux differently if > > ELF header type is "ET_DYN". It reads the symbol values incorrectly. > > Weird. > > > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but > > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is > > performing some relocation. > > > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). > > Does it take a kernel core file to reproduce this problem? > Or can you just open up gdb on a vmlinux and look at the symbol > address? It takes a core file to reproduce the problem. Without core file gdb can get right symbol addresses. > > At least without a core file it is working on with gdb 6.4. > This seems to be a problem with gdb 6.5. I transferred the dump to a different machine having GNU gdb 6.4, and it works fine there. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 5:06 ` Vivek Goyal @ 2007-05-01 5:26 ` Eric W. Biederman -1 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 5:26 UTC (permalink / raw) To: vgoyal Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton Vivek Goyal <vgoyal@in.ibm.com> writes: >> At least without a core file it is working on with gdb 6.4. >> > > This seems to be a problem with gdb 6.5. I transferred the dump to a > different machine having GNU gdb 6.4, and it works fine there. Ok. The difference between those two symbols didn't seem to make any sense, so a gdb bug makes sense. Cool. Then the patch is good. :) Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 5:26 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 5:26 UTC (permalink / raw) To: vgoyal Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan, Helge Hafting, Horms, Andrew Morton Vivek Goyal <vgoyal@in.ibm.com> writes: >> At least without a core file it is working on with gdb 6.4. >> > > This seems to be a problem with gdb 6.5. I transferred the dump to a > different machine having GNU gdb 6.4, and it works fine there. Ok. The difference between those two symbols didn't seem to make any sense, so a gdb bug makes sense. Cool. Then the patch is good. :) Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 5:26 ` Eric W. Biederman @ 2007-05-01 6:25 ` Andi Kleen -1 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-05-01 6:25 UTC (permalink / raw) To: Eric W. Biederman Cc: vgoyal, Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > >> At least without a core file it is working on with gdb 6.4. > >> > > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > Ok. The difference between those two symbols didn't seem to make > any sense, so a gdb bug makes sense. > > Cool. Then the patch is good. :) It would still make any gdb 6.5 users unhappy. If no workaround can be found I guess we'll need a CONFIG of some sort? -Andi ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 6:25 ` Andi Kleen 0 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-05-01 6:25 UTC (permalink / raw) To: Eric W. Biederman Cc: Horms, linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan, Helge Hafting, vgoyal, Andrew Morton On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > >> At least without a core file it is working on with gdb 6.4. > >> > > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > Ok. The difference between those two symbols didn't seem to make > any sense, so a gdb bug makes sense. > > Cool. Then the patch is good. :) It would still make any gdb 6.5 users unhappy. If no workaround can be found I guess we'll need a CONFIG of some sort? -Andi _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 6:25 ` Andi Kleen @ 2007-05-01 5:54 ` Eric W. Biederman -1 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 5:54 UTC (permalink / raw) To: Andi Kleen Cc: vgoyal, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton Andi Kleen <ak@suse.de> writes: > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: >> Vivek Goyal <vgoyal@in.ibm.com> writes: >> >> >> >> At least without a core file it is working on with gdb 6.4. >> >> >> > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a >> > different machine having GNU gdb 6.4, and it works fine there. >> >> Ok. The difference between those two symbols didn't seem to make >> any sense, so a gdb bug makes sense. >> >> Cool. Then the patch is good. :) > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > I guess we'll need a CONFIG of some sort? It is probably worth reproducing this bug with a PIE executable. But it looks very much like gdb got it wrong, or else there is some slight mismatch between our core dump and gdb. Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction with a core dump I would not say the problem is in vmlinux. Rather there seems to be something messed up when gdb 6.5 tries to match up the kernel core dump with the kernel. The offset for the symbol Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... Vivek could we see the program headers of your core file? >From what I can tell what is left to figure out is do we have a bug in gdb 6.5 or do we have a bug in our core file generation. Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it wrong. I'm probably just burnt out with binutils problems whenever I try and do something interesting. But I'm just not inclined that the bleeding edge tools are working properly while there kernel core dump mechanism would mess up with a two byte field change. It does make sense to root cause this if we can. If it's a gdb problem it should also apply to PIE executables, and should irritate a few users. Regardless last I heard it was crash that was the primary analysis tool and not gdb anyway. With gdb serving as the double check to make certain that the kernel core dump was in a reasonably standard format. Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 5:54 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-05-01 5:54 UTC (permalink / raw) To: Andi Kleen Cc: Horms, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, vgoyal, Andrew Morton Andi Kleen <ak@suse.de> writes: > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: >> Vivek Goyal <vgoyal@in.ibm.com> writes: >> >> >> >> At least without a core file it is working on with gdb 6.4. >> >> >> > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a >> > different machine having GNU gdb 6.4, and it works fine there. >> >> Ok. The difference between those two symbols didn't seem to make >> any sense, so a gdb bug makes sense. >> >> Cool. Then the patch is good. :) > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > I guess we'll need a CONFIG of some sort? It is probably worth reproducing this bug with a PIE executable. But it looks very much like gdb got it wrong, or else there is some slight mismatch between our core dump and gdb. Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction with a core dump I would not say the problem is in vmlinux. Rather there seems to be something messed up when gdb 6.5 tries to match up the kernel core dump with the kernel. The offset for the symbol Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... Vivek could we see the program headers of your core file? From what I can tell what is left to figure out is do we have a bug in gdb 6.5 or do we have a bug in our core file generation. Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it wrong. I'm probably just burnt out with binutils problems whenever I try and do something interesting. But I'm just not inclined that the bleeding edge tools are working properly while there kernel core dump mechanism would mess up with a two byte field change. It does make sense to root cause this if we can. If it's a gdb problem it should also apply to PIE executables, and should irritate a few users. Regardless last I heard it was crash that was the primary analysis tool and not gdb anyway. With gdb serving as the double check to make certain that the kernel core dump was in a reasonably standard format. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 5:54 ` Eric W. Biederman @ 2007-05-01 6:44 ` Vivek Goyal -1 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 6:44 UTC (permalink / raw) To: Eric W. Biederman Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms, Andrew Morton On Mon, Apr 30, 2007 at 11:54:22PM -0600, Eric W. Biederman wrote: > Andi Kleen <ak@suse.de> writes: > > > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > >> Vivek Goyal <vgoyal@in.ibm.com> writes: > >> > >> > >> >> At least without a core file it is working on with gdb 6.4. > >> >> > >> > > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a > >> > different machine having GNU gdb 6.4, and it works fine there. > >> > >> Ok. The difference between those two symbols didn't seem to make > >> any sense, so a gdb bug makes sense. > >> > >> Cool. Then the patch is good. :) > > > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > > I guess we'll need a CONFIG of some sort? > > It is probably worth reproducing this bug with a PIE executable. > But it looks very much like gdb got it wrong, or else there is some > slight mismatch between our core dump and gdb. > > Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction > with a core dump I would not say the problem is in vmlinux. > > Rather there seems to be something messed up when gdb 6.5 tries to match > up the kernel core dump with the kernel. The offset for the symbol > Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... > > Vivek could we see the program headers of your core file? > Hi Eric, Following are program headers of my core file. They look sane. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000 0x0000000000000b20 0x0000000000000b20 0 LOAD 0x0000000000000cb0 0xffffffff80200000 0x0000000000200000 0x0000000000742000 0x0000000000742000 RWE 0 LOAD 0x0000000000742cb0 0xffff810000000000 0x0000000000000000 0x00000000000a0000 0x00000000000a0000 RWE 0 LOAD 0x00000000007e2cb0 0xffff810000100000 0x0000000000100000 0x0000000000f00000 0x0000000000f00000 RWE 0 LOAD 0x00000000016e2cb0 0xffff810009000000 0x0000000009000000 0x00000000c6f8dc80 0x00000000c6f8dc80 RWE 0 LOAD 0x00000000c8670930 0xffff810100000000 0x0000000100000000 0x0000000130000000 0x0000000130000000 RWE 0 First PT_LOAD header is mapping kernel text/data and others just mapping physical memory in kernel linear virtual address range. > >From what I can tell what is left to figure out is do we have > a bug in gdb 6.5 or do we have a bug in our core file generation. > Given the fact it works well with gdb 6.4 as well as 6.1 (crash uses gdb 6.1 as backend and crash is working fine). I would think that it is gdb bug. > Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it > wrong. I'm probably just burnt out with binutils problems whenever > I try and do something interesting. But I'm just not inclined that > the bleeding edge tools are working properly while there kernel > core dump mechanism would mess up with a two byte field change. > > It does make sense to root cause this if we can. If it's a gdb > problem it should also apply to PIE executables, and should irritate > a few users. > > Regardless last I heard it was crash that was the primary analysis > tool and not gdb anyway. With gdb serving as the double check to make > certain that the kernel core dump was in a reasonably standard format. I would consider gdb to be equally important, especially because many a times crash is broken with latest version of kernels (as some data structures or some mechanism has changed) and gdb is the only one who can open the dump. Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-01 6:44 ` Vivek Goyal 0 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-01 6:44 UTC (permalink / raw) To: Eric W. Biederman Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan, Helge Hafting, Horms, Andrew Morton On Mon, Apr 30, 2007 at 11:54:22PM -0600, Eric W. Biederman wrote: > Andi Kleen <ak@suse.de> writes: > > > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > >> Vivek Goyal <vgoyal@in.ibm.com> writes: > >> > >> > >> >> At least without a core file it is working on with gdb 6.4. > >> >> > >> > > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a > >> > different machine having GNU gdb 6.4, and it works fine there. > >> > >> Ok. The difference between those two symbols didn't seem to make > >> any sense, so a gdb bug makes sense. > >> > >> Cool. Then the patch is good. :) > > > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > > I guess we'll need a CONFIG of some sort? > > It is probably worth reproducing this bug with a PIE executable. > But it looks very much like gdb got it wrong, or else there is some > slight mismatch between our core dump and gdb. > > Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction > with a core dump I would not say the problem is in vmlinux. > > Rather there seems to be something messed up when gdb 6.5 tries to match > up the kernel core dump with the kernel. The offset for the symbol > Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... > > Vivek could we see the program headers of your core file? > Hi Eric, Following are program headers of my core file. They look sane. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000 0x0000000000000b20 0x0000000000000b20 0 LOAD 0x0000000000000cb0 0xffffffff80200000 0x0000000000200000 0x0000000000742000 0x0000000000742000 RWE 0 LOAD 0x0000000000742cb0 0xffff810000000000 0x0000000000000000 0x00000000000a0000 0x00000000000a0000 RWE 0 LOAD 0x00000000007e2cb0 0xffff810000100000 0x0000000000100000 0x0000000000f00000 0x0000000000f00000 RWE 0 LOAD 0x00000000016e2cb0 0xffff810009000000 0x0000000009000000 0x00000000c6f8dc80 0x00000000c6f8dc80 RWE 0 LOAD 0x00000000c8670930 0xffff810100000000 0x0000000100000000 0x0000000130000000 0x0000000130000000 RWE 0 First PT_LOAD header is mapping kernel text/data and others just mapping physical memory in kernel linear virtual address range. > >From what I can tell what is left to figure out is do we have > a bug in gdb 6.5 or do we have a bug in our core file generation. > Given the fact it works well with gdb 6.4 as well as 6.1 (crash uses gdb 6.1 as backend and crash is working fine). I would think that it is gdb bug. > Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it > wrong. I'm probably just burnt out with binutils problems whenever > I try and do something interesting. But I'm just not inclined that > the bleeding edge tools are working properly while there kernel > core dump mechanism would mess up with a two byte field change. > > It does make sense to root cause this if we can. If it's a gdb > problem it should also apply to PIE executables, and should irritate > a few users. > > Regardless last I heard it was crash that was the primary analysis > tool and not gdb anyway. With gdb serving as the double check to make > certain that the kernel core dump was in a reasonably standard format. I would consider gdb to be equally important, especially because many a times crash is broken with latest version of kernels (as some data structures or some mechanism has changed) and gdb is the only one who can open the dump. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-01 5:06 ` Vivek Goyal @ 2007-05-28 10:54 ` Bernhard Walle -1 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-05-28 10:54 UTC (permalink / raw) To: Andi Kleen, vgoyal; +Cc: kexec, linux-kernel * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > This seems to be a problem with gdb 6.5. I transferred the dump to a > different machine having GNU gdb 6.4, and it works fine there. What's the state of it? Andy, was the GDB breakage the reason why you didn't merge it? Did someone file a GDB bug? Thanks, Bernhard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-28 10:54 ` Bernhard Walle 0 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-05-28 10:54 UTC (permalink / raw) To: Andi Kleen, vgoyal; +Cc: kexec, linux-kernel * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > This seems to be a problem with gdb 6.5. I transferred the dump to a > different machine having GNU gdb 6.4, and it works fine there. What's the state of it? Andy, was the GDB breakage the reason why you didn't merge it? Did someone file a GDB bug? Thanks, Bernhard _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-28 10:54 ` Bernhard Walle @ 2007-05-28 11:09 ` Vivek Goyal -1 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-28 11:09 UTC (permalink / raw) To: Andi Kleen, kexec, linux-kernel, Bernhard Walle On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > What's the state of it? Andy, was the GDB breakage the reason why you > didn't merge it? Did someone file a GDB bug? > I had sent a mail to gdb mailing list but no response. Did not raise a bug though. Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-28 11:09 ` Vivek Goyal 0 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-05-28 11:09 UTC (permalink / raw) To: Andi Kleen, kexec, linux-kernel, Bernhard Walle On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > What's the state of it? Andy, was the GDB breakage the reason why you > didn't merge it? Did someone file a GDB bug? > I had sent a mail to gdb mailing list but no response. Did not raise a bug though. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-28 11:09 ` Vivek Goyal @ 2007-05-28 14:39 ` Bernhard Walle -1 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-05-28 14:39 UTC (permalink / raw) To: Vivek Goyal; +Cc: Andi Kleen, kexec, linux-kernel * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]: > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > > different machine having GNU gdb 6.4, and it works fine there. > > > > What's the state of it? Andy, was the GDB breakage the reason why you > > didn't merge it? Did someone file a GDB bug? > > I had sent a mail to gdb mailing list but no response. Did not raise > a bug though. BTW: Did anyone test with GDB 6.6? Thanks, Bernhard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-28 14:39 ` Bernhard Walle 0 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-05-28 14:39 UTC (permalink / raw) To: Vivek Goyal; +Cc: kexec, Andi Kleen, linux-kernel * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]: > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > > different machine having GNU gdb 6.4, and it works fine there. > > > > What's the state of it? Andy, was the GDB breakage the reason why you > > didn't merge it? Did someone file a GDB bug? > > I had sent a mail to gdb mailing list but no response. Did not raise > a bug though. BTW: Did anyone test with GDB 6.6? Thanks, Bernhard _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-28 14:39 ` Bernhard Walle @ 2007-06-01 12:26 ` Bernhard Walle -1 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-06-01 12:26 UTC (permalink / raw) To: Vivek Goyal, Andi Kleen, kexec, linux-kernel * Bernhard Walle <bwalle@suse.de> [2007-05-28 16:39]: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]: > > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > > > different machine having GNU gdb 6.4, and it works fine there. > > > > > > What's the state of it? Andy, was the GDB breakage the reason why you > > > didn't merge it? Did someone file a GDB bug? > > > > I had sent a mail to gdb mailing list but no response. Did not raise > > a bug though. > > BTW: Did anyone test with GDB 6.6? /me. But I get the same error as with GDB 6.5. I'm looking if I can find the cause of the problem. Thanks, Bernhard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-06-01 12:26 ` Bernhard Walle 0 siblings, 0 replies; 34+ messages in thread From: Bernhard Walle @ 2007-06-01 12:26 UTC (permalink / raw) To: Vivek Goyal, Andi Kleen, kexec, linux-kernel * Bernhard Walle <bwalle@suse.de> [2007-05-28 16:39]: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]: > > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote: > > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > > > different machine having GNU gdb 6.4, and it works fine there. > > > > > > What's the state of it? Andy, was the GDB breakage the reason why you > > > didn't merge it? Did someone file a GDB bug? > > > > I had sent a mail to gdb mailing list but no response. Did not raise > > a bug though. > > BTW: Did anyone test with GDB 6.6? /me. But I get the same error as with GDB 6.5. I'm looking if I can find the cause of the problem. Thanks, Bernhard _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-05-28 10:54 ` Bernhard Walle @ 2007-05-28 14:57 ` Andi Kleen -1 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-05-28 14:57 UTC (permalink / raw) To: Bernhard Walle; +Cc: vgoyal, kexec, linux-kernel On Monday 28 May 2007 12:54:42 Bernhard Walle wrote: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > What's the state of it? Andy, was the GDB breakage the reason why you > didn't merge it? Yes, I was waiting for Vivek to figure that out. -Andi ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-05-28 14:57 ` Andi Kleen 0 siblings, 0 replies; 34+ messages in thread From: Andi Kleen @ 2007-05-28 14:57 UTC (permalink / raw) To: Bernhard Walle; +Cc: vgoyal, kexec, linux-kernel On Monday 28 May 2007 12:54:42 Bernhard Walle wrote: > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]: > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > What's the state of it? Andy, was the GDB breakage the reason why you > didn't merge it? Yes, I was waiting for Vivek to figure that out. -Andi _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
@ 2007-03-31 7:53 Andrew Morton
2007-04-01 5:29 ` thunder7
0 siblings, 1 reply; 34+ messages in thread
From: Andrew Morton @ 2007-03-31 7:53 UTC (permalink / raw)
To: Helge Hafting; +Cc: linux-kernel, Vivek Goyal, Eric W. Biederman
On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <helgehaf@aitel.hist.no> wrote:
> A new error for me:
>
> loading 2.6.21rc5mm3
> Bios data check successful
> Destination address not 2M aligned
> -- System halted
>
>
> This is using the same lilo that loads 2.6.18rc5mm1 fine.
> x86-64
>
That's new. Does changing the value of CONFIG_RELOCATABLE change anything?
Please send the .config.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-03-31 7:53 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Andrew Morton @ 2007-04-01 5:29 ` thunder7 2007-04-01 6:15 ` Eric W. Biederman 0 siblings, 1 reply; 34+ messages in thread From: thunder7 @ 2007-04-01 5:29 UTC (permalink / raw) To: Andrew Morton; +Cc: Helge Hafting, linux-kernel, Vivek Goyal, Eric W. Biederman From: Andrew Morton <akpm@linux-foundation.org> Date: Sat, Mar 31, 2007 at 12:53:03AM -0700 > On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <helgehaf@aitel.hist.no> wrote: > > > A new error for me: > > > > loading 2.6.21rc5mm3 > > Bios data check successful > > Destination address not 2M aligned > > -- System halted > > > > > > This is using the same lilo that loads 2.6.18rc5mm1 fine. > > x86-64 > > > > That's new. Does changing the value of CONFIG_RELOCATABLE change anything? > > Please send the .config. > I had the same with this .config from 2.6.21-rc3-mm2 after running 'make oldconfig' and answering N to all new questions. Then, I tweaked some items, mostly to see if there was an 'align kernel' item in there somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted 'CONFIG_PHYSICAL_START', maybe that's it? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc3-mm2 # Tue Mar 13 18:35:46 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_NR_CPUS=2 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_PROCFS is not set CONFIG_ACPI_AC=y # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_ACPI_CPUFREQ=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # # CPU idle PM support # # CONFIG_CPU_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_DOMAINS is not set CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_IA32_EMULATION is not set # # Networking # CONFIG_NET=y # # Networking options # # CONFIG_NETDEBUG is not set CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_MULTIPLE_TABLES is not set # CONFIG_IP_ROUTE_MULTIPATH is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y CONFIG_NET_IPGRE_BROADCAST=y # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y CONFIG_INET_XFRM_TUNNEL=y CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # Core Netfilter Configuration # # CONFIG_NETFILTER_NETLINK is not set CONFIG_NF_CONNTRACK_ENABLED=y CONFIG_NF_CONNTRACK_SUPPORT=y # CONFIG_IP_NF_CONNTRACK_SUPPORT is not set CONFIG_NF_CONNTRACK=y CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m # CONFIG_NF_CONNTRACK_SANE is not set CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m # CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # # TIPC Configuration (EXPERIMENTAL) # # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_FIFO=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set # CONFIG_CLS_U32_MARK is not set CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_EMATCH is not set # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # CONFIG_NET_CLS_IND is not set CONFIG_NET_ESTIMATOR=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=32 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # # Misc devices # # CONFIG_IBM_ASM is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_IDE_MAX_HWIFS=12 CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=y # CONFIG_BLK_DEV_IDEACPI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # # CONFIG_IDE_GENERIC is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set CONFIG_IDEPCI_PCIBUS_ORDER=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set CONFIG_BLK_DEV_HPT366=y # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_IT8213 is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_BLK_DEV_TC86C001 is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set CONFIG_SCSI_HPTIOP=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set # # Serial ATA (prod) and Parallel ATA (experimental) drivers # CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_SATA_AHCI=y # CONFIG_SATA_SVW is not set # CONFIG_ATA_PIIX is not set # CONFIG_SATA_MV is not set CONFIG_SATA_NV=y # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set CONFIG_SATA_SIL=y CONFIG_SATA_SIL24=y # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set CONFIG_SATA_INTEL_COMBINED=y CONFIG_SATA_ACPI=y # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_PLATFORM is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID10=y CONFIG_MD_RAID456=y CONFIG_MD_RAID5_RESHAPE=y # CONFIG_MD_MULTIPATH is not set # CONFIG_MD_FAULTY is not set # CONFIG_BLK_DEV_DM is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # # CONFIG_FW is not set CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y CONFIG_IEEE1394_CONFIG_ROM_IP1394=y # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_SBP2=y # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_DV1394=y CONFIG_IEEE1394_RAWIO=y # # I2O device support # # CONFIG_I2O is not set # # Macintosh device drivers # # CONFIG_MAC_EMUMOUSEBTN is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # ARCnet devices # CONFIG_ARCNET=m CONFIG_ARCNET_1201=m CONFIG_ARCNET_1051=m CONFIG_ARCNET_RAW=m # CONFIG_ARCNET_CAP is not set CONFIG_ARCNET_COM90xx=m CONFIG_ARCNET_COM90xxIO=m CONFIG_ARCNET_RIM_I=m CONFIG_ARCNET_COM20020=m CONFIG_ARCNET_COM20020_PCI=m # # PHY device support # CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_QSEMI_PHY=y CONFIG_LXT_PHY=y CONFIG_CICADA_PHY=y # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_FIXED_PHY is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set CONFIG_TULIP=y # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set CONFIG_FORCEDETH=y CONFIG_FORCEDETH_NAPI=y # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_VIA_RHINE is not set # CONFIG_SC92031 is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set CONFIG_SKGE=y # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # # Ethernet (10000 Mbit) # # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_IXGB is not set # CONFIG_S2IO is not set # CONFIG_MYRI10GE is not set # CONFIG_NETXEN_NIC is not set # CONFIG_VIOC is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_RTL818X is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_UINPUT is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_DONT_TEST_BUG_TXEN is not set CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_SC520_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m # CONFIG_IBMASR is not set CONFIG_WAFER_WDT=m # CONFIG_I6300ESB_WDT is not set CONFIG_I8XX_TCO=m # CONFIG_ITCO_WDT is not set CONFIG_SC1200_WDT=m # CONFIG_PC87413_WDT is not set CONFIG_60XX_WDT=m # CONFIG_SBC8360_WDT is not set CONFIG_CPU5_WDT=m # CONFIG_SMSC37B787_WDT is not set CONFIG_W83627HF_WDT=m # CONFIG_W83697HF_WDT is not set CONFIG_W83877F_WDT=m # CONFIG_W83977F_WDT is not set CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_INTEL is not set CONFIG_HW_RANDOM_AMD=y # CONFIG_HW_RANDOM_GEODE is not set CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set CONFIG_AGP=y CONFIG_AGP_AMD64=y # CONFIG_AGP_INTEL is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_VIA is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=y # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set # # I2C support # CONFIG_I2C=y CONFIG_I2C_CHARDEV=y # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PASEMI is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Hardware Monitoring support # CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set CONFIG_SENSORS_K8TEMP=m # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set CONFIG_SENSORS_IT87=m # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set CONFIG_SENSORS_W83791D=m # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # CONFIG_USB_DABUSB is not set # # Graphics support # CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # # Frambuffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=y CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_NVIDIA_BACKLIGHT=y # CONFIG_FB_RIVA is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FONTS=y # CONFIG_FONT_8x8 is not set # CONFIG_FONT_8x16 is not set # CONFIG_FONT_6x11 is not set # CONFIG_FONT_7x14 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set CONFIG_FONT_10x18=y # # Logo configuration # CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y # CONFIG_SND_DYNAMIC_MINORS is not set # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_AC97_CODEC=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDA_INTEL is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_AC97_POWER_SAVE is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # SoC audio support # # CONFIG_SND_SOC is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m # # HID Devices # CONFIG_HID=y # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_UHCI_HCD is not set # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # # CONFIG_USB_STORAGE is not set # CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # # CONFIG_USB_HID is not set # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_TOUCHSCREEN is not set # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set # CONFIG_USB_GTCO is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET_MII is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_MON is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GOTEMP is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # LED devices # # CONFIG_NEW_LEDS is not set # # LED drivers # # # LED Triggers # # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_MM_EDAC=y # CONFIG_EDAC_E752X is not set CONFIG_EDAC_K8=y CONFIG_EDAC_POLL=y # # Real Time Clock # CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # # RTC drivers # CONFIG_RTC_DRV_CMOS=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_M48T86=m # CONFIG_RTC_DRV_TEST is not set CONFIG_RTC_DRV_V3020=m # # DMA Engine support # # CONFIG_DMA_ENGINE is not set # # DMA Clients # CONFIG_ASYNC_TX_DMA=y # # DMA Devices # # # Auxiliary Display support # # # Virtualization # # CONFIG_KVM is not set # # Userspace I/O # # CONFIG_UIO is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISER4_FS is not set CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_MINIX_FS=y # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_DNOTIFY is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_CONFIGFS_FS is not set # # Layered filesystems # # CONFIG_UNION_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Distributed Lock Manager # # CONFIG_DLM is not set # # Instrumentation Support # # CONFIG_PROFILING is not set # CONFIG_KPROBES is not set # CONFIG_MARKERS is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_FRAME_POINTER=y # CONFIG_PROFILE_LIKELY is not set # CONFIG_FORCED_INLINING is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_IOMMU_DEBUG is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_INTEGRITY is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_ECB is not set CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_X86_64 is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_X86_64 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set CONFIG_CRC32=y # CONFIG_CRC_ITU_T is not set CONFIG_LIBCRC32C=y # CONFIG_EEPROM_93CX6 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y The diff between this .config and a working 2.6.21-rc5-mm3 .config: --- /usr/src/linux-2.6.21-rc3-mm2/.config 2007-03-13 18:35:46.000000000 +0100 +++ /usr/src/linux-2.6.21-rc5-mm3/.config 2007-03-31 19:50:11.000000000 +0200 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.21-rc3-mm2 -# Tue Mar 13 18:35:46 2007 +# Linux kernel version: 2.6.21-rc5-mm3 +# Sat Mar 31 19:50:11 2007 # CONFIG_X86_64=y CONFIG_64BIT=y @@ -61,8 +61,8 @@ # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y -CONFIG_EMBEDDED=y -# CONFIG_SYSCTL_SYSCALL is not set +# CONFIG_EMBEDDED is not set +CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set @@ -75,15 +75,12 @@ CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y -# CONFIG_VM_EVENT_COUNTERS is not set -CONFIG_CLASSIC_RCU=y -# CONFIG_PREEMPT_RCU is not set -# CONFIG_RCU_TRACE is not set +CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set -CONFIG_PAGE_GROUP_BY_MOBILITY=y +# CONFIG_PAGE_GROUP_BY_MOBILITY is not set # # Loadable module support @@ -175,7 +172,8 @@ CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set -CONFIG_PHYSICAL_START=0x100000 +# CONFIG_RELOCATABLE is not set +CONFIG_PHYSICAL_START=0x200000 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set @@ -212,7 +210,6 @@ CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set -# CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set @@ -251,7 +248,6 @@ # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set -# CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # @@ -637,12 +633,12 @@ # CONFIG_TIFM_CORE is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set +# CONFIG_ACPI_IBM is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y -CONFIG_IDE_MAX_HWIFS=12 CONFIG_BLK_DEV_IDE=y # @@ -675,7 +671,6 @@ # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set -CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set @@ -706,7 +701,6 @@ # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set -CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # @@ -736,6 +730,7 @@ CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set +CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports @@ -804,8 +799,8 @@ # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set -CONFIG_SATA_INTEL_COMBINED=y CONFIG_SATA_ACPI=y +# CONFIG_PATA_ACPI is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set @@ -842,7 +837,6 @@ # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set -# CONFIG_PATA_PLATFORM is not set # # Multi-device support (RAID and LVM) @@ -870,15 +864,13 @@ # # IEEE 1394 (FireWire) support # -# CONFIG_FW is not set +# CONFIG_FIREWIRE is not set CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set -CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y -CONFIG_IEEE1394_CONFIG_ROM_IP1394=y # # Device Drivers @@ -891,6 +883,7 @@ # CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_SBP2=y +# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_DV1394=y CONFIG_IEEE1394_RAWIO=y @@ -1133,7 +1126,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set -# CONFIG_SERIAL_8250_DONT_TEST_BUG_TXEN is not set CONFIG_SERIAL_8250_RSA=y # @@ -1230,6 +1222,7 @@ # I2C support # CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=y # @@ -1264,7 +1257,6 @@ # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set -# CONFIG_I2C_PCA_ISA is not set # # Miscellaneous I2C Chip support @@ -1299,6 +1291,7 @@ CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_SENSORS_ABITUGURU is not set +# CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set @@ -1314,6 +1307,7 @@ # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set +# CONFIG_SENSORS_CORETEMP is not set CONFIG_SENSORS_IT87=m # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set @@ -1326,6 +1320,7 @@ # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set +# CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set @@ -1343,6 +1338,7 @@ # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set +# CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set # @@ -1558,6 +1554,7 @@ # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set +# CONFIG_SND_USB_CAIAQ is not set # # SoC audio support @@ -1578,6 +1575,17 @@ # CONFIG_HIDRAW is not set # +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +CONFIG_USB_KBD=m +CONFIG_USB_MOUSE=m + +# # USB support # CONFIG_USB_ARCH_HAS_HCD=y @@ -1590,6 +1598,7 @@ # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y +# CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set @@ -1629,13 +1638,6 @@ # # USB Input Devices # -# CONFIG_USB_HID is not set - -# -# USB HID Boot Protocol drivers -# -CONFIG_USB_KBD=m -CONFIG_USB_MOUSE=m # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set @@ -1763,24 +1765,38 @@ CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set +# CONFIG_RTC_DRV_TEST is not set # -# RTC drivers +# I2C RTC drivers # -CONFIG_RTC_DRV_CMOS=m -CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_DS1307=m -CONFIG_RTC_DRV_DS1553=m -CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_DS1672=m -CONFIG_RTC_DRV_DS1742=m -CONFIG_RTC_DRV_PCF8563=m +CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m +CONFIG_RTC_DRV_ISL1208=m +CONFIG_RTC_DRV_X1205=m +CONFIG_RTC_DRV_PCF8563=m +# CONFIG_RTC_DRV_PCF8583 is not set + +# +# SPI RTC drivers +# + +# +# Platform RTC drivers +# +CONFIG_RTC_DRV_CMOS=m +CONFIG_RTC_DRV_DS1553=m +CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_M48T86=m -# CONFIG_RTC_DRV_TEST is not set CONFIG_RTC_DRV_V3020=m # +# on-CPU RTC drivers +# + +# # DMA Engine support # # CONFIG_DMA_ENGINE is not set @@ -1846,7 +1862,7 @@ CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set -# CONFIG_DNOTIFY is not set +CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set @@ -2014,6 +2030,8 @@ # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_FRAME_POINTER=y +CONFIG_UNWIND_INFO=y +CONFIG_STACK_UNWIND=y # CONFIG_PROFILE_LIKELY is not set # CONFIG_FORCED_INLINING is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set Kind regards, Jurriaan -- I am the widget missing from the easy to assemble swingset Darkwing Duck Debian (Unstable) GNU/Linux 2.6.21-rc5-mm3 2x2010 bogomips load 0.39 the Jack Vance Integral Edition: http://www.integralarchive.org ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-01 5:29 ` thunder7 @ 2007-04-01 6:15 ` Eric W. Biederman 2007-04-01 6:29 ` Andrew Morton 0 siblings, 1 reply; 34+ messages in thread From: Eric W. Biederman @ 2007-04-01 6:15 UTC (permalink / raw) To: Jurriaan; +Cc: Andrew Morton, Helge Hafting, linux-kernel, Vivek Goyal thunder7@xs4all.nl writes: > I had the same with this .config from 2.6.21-rc3-mm2 after running 'make > oldconfig' and answering N to all new questions. Then, I tweaked some > items, mostly to see if there was an 'align kernel' item in there > somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this > 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted > 'CONFIG_PHYSICAL_START', maybe that's it? That looks like it. Does anyone know how to express the constraint of a 2M aligned number in Kconfig? The original plan was to remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE on x86_64 because after this series they have no cost and thus just lead to a little more confusion. However because we don't tag vmlinux as ET_DYN and Xen has some use for kernel built at different physical addresses (or at least loaded at them), and because Xen directly loads vmlinux he kept those options. If we can find a place to stick it into the build doing a little post processing of vmlinux so that it has the proper ELF header type (ET_DYN not ET_EXEC) would be useful and allow us to remove those extra confusing options. If I have a spare moment I will take a look. Since there is confusion it is probably worth removing the unnecessary confusing options if we can instead of supporting the full confusion. Doing the same for i386 would be a little harder but with Dave Miller's suggestions for Xen and leaving the functions to be replaced unlinked so the compiler generates efficient calls and then doing linking magic to fill in the pieces at boot looks about as tricky as moving the relocation logic for i386 into vmlinux as well. So it seems feasible and possibly worth doing. Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-01 6:15 ` Eric W. Biederman @ 2007-04-01 6:29 ` Andrew Morton 2007-04-02 7:41 ` Vivek Goyal 0 siblings, 1 reply; 34+ messages in thread From: Andrew Morton @ 2007-04-01 6:29 UTC (permalink / raw) To: Eric W. Biederman; +Cc: Jurriaan, Helge Hafting, linux-kernel, Vivek Goyal On Sun, 01 Apr 2007 00:15:51 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote: > Does anyone know how to express the constraint of a 2M aligned number in Kconfig? Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which would be a bit hard to use. Adding a BUILD_BUG_ON which checks this constraint might help. Plus a useful comment right at the BUILD_BUG_ON site explaining what to do about it. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-01 6:29 ` Andrew Morton @ 2007-04-02 7:41 ` Vivek Goyal 2007-04-02 8:43 ` Eric W. Biederman 0 siblings, 1 reply; 34+ messages in thread From: Vivek Goyal @ 2007-04-02 7:41 UTC (permalink / raw) To: Andrew Morton; +Cc: Eric W. Biederman, Jurriaan, Helge Hafting, linux-kernel On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote: > On Sun, 01 Apr 2007 00:15:51 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote: > > > Does anyone know how to express the constraint of a 2M aligned number in Kconfig? > > Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which > would be a bit hard to use. > > Adding a BUILD_BUG_ON which checks this constraint might help. Plus a > useful comment right at the BUILD_BUG_ON site explaining what to do about > it. How about attached patch? Thanks Vivek o X86_64 kernel should run from 2MB aligned address for two reasons. - Performance. - For relocatable kernels, page tables are updated based on difference between compile time address and load time physical address. This difference should be multiple of 2MB as kernel text and data is mapped using 2MB pages and PMD should be pointing to a 2MB aligned address. Life is simpler if both compile time and load time kernel addresses are 2MB aligned. o Flag the error at compile time if one is trying to build a kernel which does not meet alignment restrictions. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> --- arch/x86_64/kernel/head64.c | 8 ++++++++ include/asm-x86_64/page.h | 1 + 2 files changed, 9 insertions(+) diff -puN arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M arch/x86_64/kernel/head64.c --- linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:46:43.000000000 +0530 +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02 21:20:45.000000000 +0530 @@ -62,6 +62,14 @@ void __init x86_64_start_kernel(char * r { int i; + /* + * Make sure kernel is aligned to 2MB address. Catching it at compile + * time is better. Change your config file and compile the kernel + * for a 2MB aligned address (CONFIG_PHYSICAL_START) + */ + BUILD_BUG_ON(ALIGN(CONFIG_PHYSICAL_START, __KERNEL_ALIGN) + != CONFIG_PHYSICAL_START); + /* clear bss before set_intr_gate with early_idt_handler */ clear_bss(); diff -puN include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M include/asm-x86_64/page.h --- linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:50:55.000000000 +0530 +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02 20:51:34.000000000 +0530 @@ -79,6 +79,7 @@ extern unsigned long phys_base; #endif /* !__ASSEMBLY__ */ #define __PHYSICAL_START CONFIG_PHYSICAL_START +#define __KERNEL_ALIGN 0x200000 #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) #define __START_KERNEL_map 0xffffffff80000000 #define __PAGE_OFFSET 0xffff810000000000 _ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-02 7:41 ` Vivek Goyal @ 2007-04-02 8:43 ` Eric W. Biederman 2007-04-02 9:45 ` Vivek Goyal 0 siblings, 1 reply; 34+ messages in thread From: Eric W. Biederman @ 2007-04-02 8:43 UTC (permalink / raw) To: vgoyal; +Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel Vivek Goyal <vgoyal@in.ibm.com> writes: > On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote: >> On Sun, 01 Apr 2007 00:15:51 -0600 ebiederm@xmission.com (Eric W. Biederman) > wrote: >> >> > Does anyone know how to express the constraint of a 2M aligned number in > Kconfig? >> >> Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which >> would be a bit hard to use. >> >> Adding a BUILD_BUG_ON which checks this constraint might help. Plus a >> useful comment right at the BUILD_BUG_ON site explaining what to do about >> it. > > How about attached patch? Looks like that will work. Vivek. If I can get the x86_64 vmlinux to have type ET_DYN (to mark it as relocatable) is there any reason to keep CONFIG_PHYSICAL_START? I think I can switch the vmlinux header type in about 100 lines or so of code. Assuming I can ever get 30 minutes with the appropriate kernel. > Thanks > Vivek > > > > o X86_64 kernel should run from 2MB aligned address for two reasons. > - Performance. > - For relocatable kernels, page tables are updated based on difference > between compile time address and load time physical address. > This difference should be multiple of 2MB as kernel text and data > is mapped using 2MB pages and PMD should be pointing to a 2MB > aligned address. Life is simpler if both compile time and load time > kernel addresses are 2MB aligned. > > o Flag the error at compile time if one is trying to build a kernel which > does not meet alignment restrictions. > > Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> > --- > > arch/x86_64/kernel/head64.c | 8 ++++++++ > include/asm-x86_64/page.h | 1 + > 2 files changed, 9 insertions(+) > > diff -puN > arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M > arch/x86_64/kernel/head64.c > --- > linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M > 2007-04-02 20:46:43.000000000 +0530 > +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02 > 21:20:45.000000000 +0530 > @@ -62,6 +62,14 @@ void __init x86_64_start_kernel(char * r > { > int i; > > + /* > + * Make sure kernel is aligned to 2MB address. Catching it at compile > + * time is better. Change your config file and compile the kernel > + * for a 2MB aligned address (CONFIG_PHYSICAL_START) > + */ > + BUILD_BUG_ON(ALIGN(CONFIG_PHYSICAL_START, __KERNEL_ALIGN) > + != CONFIG_PHYSICAL_START); Just as a nit. BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1)) is a little shorter... Although maybe not quite as readable. > + > /* clear bss before set_intr_gate with early_idt_handler */ > clear_bss(); > > diff -puN > include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M > include/asm-x86_64/page.h > --- > linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M > 2007-04-02 20:50:55.000000000 +0530 > +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02 > 20:51:34.000000000 +0530 > @@ -79,6 +79,7 @@ extern unsigned long phys_base; > #endif /* !__ASSEMBLY__ */ > > #define __PHYSICAL_START CONFIG_PHYSICAL_START > +#define __KERNEL_ALIGN 0x200000 > #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) > #define __START_KERNEL_map 0xffffffff80000000 > #define __PAGE_OFFSET 0xffff810000000000 Do we want to use the __KERNEL_ALIGN directive in the test in misc.c? Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-02 8:43 ` Eric W. Biederman @ 2007-04-02 9:45 ` Vivek Goyal 2007-04-02 17:26 ` Eric W. Biederman 0 siblings, 1 reply; 34+ messages in thread From: Vivek Goyal @ 2007-04-02 9:45 UTC (permalink / raw) To: Eric W. Biederman; +Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel On Mon, Apr 02, 2007 at 02:43:56AM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote: > >> On Sun, 01 Apr 2007 00:15:51 -0600 ebiederm@xmission.com (Eric W. Biederman) > > wrote: > >> > >> > Does anyone know how to express the constraint of a 2M aligned number in > > Kconfig? > >> > >> Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which > >> would be a bit hard to use. > >> > >> Adding a BUILD_BUG_ON which checks this constraint might help. Plus a > >> useful comment right at the BUILD_BUG_ON site explaining what to do about > >> it. > > > > How about attached patch? > > Looks like that will work. > > Vivek. If I can get the x86_64 vmlinux to have type ET_DYN (to mark > it as relocatable) is there any reason to keep CONFIG_PHYSICAL_START? Only advantage of CONFIG_PHYSICAL_START seems to be that one has got capability to run the kernel from other addresses without modifying the boot-loader. One can argue that now people should use a relocatable kernel for such a feature. But for using relocatable kenrel, one needs to modify grub, lilo and I am not sure if somebody is going to do that. Secondly, how would one specify an address to a boot-loader to load image at? On i386, somebody already found an interesting usage of CONFIG_PHYSICAL_START where he was running his kernel above 16MB so that he can maximize on DMA ZONE. Can't think of any usage for x86_64 at the moment but I think down the line people might come up with such usages. To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, at the expense of reduced simplicity. We should definitely change the type of vmlinux to ET_DYN but at the same time it might still be worth to retain CONFIG_PHYSICAL_START option. > I think I can switch the vmlinux header type in about 100 lines or so > of code. Assuming I can ever get 30 minutes with the appropriate > kernel. > That would be awesome. Then vmlinux will be relocatable too. (Officially). [..] > > @@ -62,6 +62,14 @@ void __init x86_64_start_kernel(char * r > > { > > int i; > > > > + /* > > + * Make sure kernel is aligned to 2MB address. Catching it at compile > > + * time is better. Change your config file and compile the kernel > > + * for a 2MB aligned address (CONFIG_PHYSICAL_START) > > + */ > > + BUILD_BUG_ON(ALIGN(CONFIG_PHYSICAL_START, __KERNEL_ALIGN) > > + != CONFIG_PHYSICAL_START); > > Just as a nit. > BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1)) > is a little shorter... Although maybe not quite as readable. This looks better. I changed it in attached patch. > > + > > /* clear bss before set_intr_gate with early_idt_handler */ > > clear_bss(); > > > > diff -puN > > include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M > > include/asm-x86_64/page.h > > --- > > linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M > > 2007-04-02 20:50:55.000000000 +0530 > > +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02 > > 20:51:34.000000000 +0530 > > @@ -79,6 +79,7 @@ extern unsigned long phys_base; > > #endif /* !__ASSEMBLY__ */ > > > > #define __PHYSICAL_START CONFIG_PHYSICAL_START > > +#define __KERNEL_ALIGN 0x200000 > > #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) > > #define __START_KERNEL_map 0xffffffff80000000 > > #define __PAGE_OFFSET 0xffff810000000000 > > Do we want to use the __KERNEL_ALIGN directive in the test in misc.c? Thanks. I changed it in misc.c too. Thanks Vivek o X86_64 kernel should run from 2MB aligned address for two reasons. - Performance. - For relocatable kernels, page tables are updated based on difference between compile time address and load time physical address. This difference should be multiple of 2MB as kernel text and data is mapped using 2MB pages and PMD should be pointing to a 2MB aligned address. Life is simpler if both compile time and load time kernel addresses are 2MB aligned. o Flag the error at compile time if one is trying to build a kernel which does not meet alignment restrictions. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> --- arch/x86_64/boot/compressed/misc.c | 2 +- arch/x86_64/kernel/head64.c | 7 +++++++ include/asm-x86_64/page.h | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) diff -puN arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M arch/x86_64/kernel/head64.c --- linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:46:43.000000000 +0530 +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02 23:03:08.000000000 +0530 @@ -62,6 +62,13 @@ void __init x86_64_start_kernel(char * r { int i; + /* + * Make sure kernel is aligned to 2MB address. Catching it at compile + * time is better. Change your config file and compile the kernel + * for a 2MB aligned address (CONFIG_PHYSICAL_START) + */ + BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1)); + /* clear bss before set_intr_gate with early_idt_handler */ clear_bss(); diff -puN include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M include/asm-x86_64/page.h --- linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 20:50:55.000000000 +0530 +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02 20:51:34.000000000 +0530 @@ -79,6 +79,7 @@ extern unsigned long phys_base; #endif /* !__ASSEMBLY__ */ #define __PHYSICAL_START CONFIG_PHYSICAL_START +#define __KERNEL_ALIGN 0x200000 #define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START) #define __START_KERNEL_map 0xffffffff80000000 #define __PAGE_OFFSET 0xffff810000000000 diff -puN arch/x86_64/boot/compressed/misc.c~x86_64-check-for-config-physical-start-aligned-2M arch/x86_64/boot/compressed/misc.c --- linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/boot/compressed/misc.c~x86_64-check-for-config-physical-start-aligned-2M 2007-04-02 23:05:20.000000000 +0530 +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/boot/compressed/misc.c 2007-04-02 23:06:09.000000000 +0530 @@ -358,7 +358,7 @@ asmlinkage void decompress_kernel(void * insize = input_len; inptr = 0; - if ((ulg)output & 0x1fffffUL) + if ((ulg)output & (__KERNEL_ALIGN - 1)) error("Destination address not 2M aligned"); if ((ulg)output >= 0xffffffffffUL) error("Destination address too large"); _ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-02 9:45 ` Vivek Goyal @ 2007-04-02 17:26 ` Eric W. Biederman 2007-04-03 4:01 ` Vivek Goyal 0 siblings, 1 reply; 34+ messages in thread From: Eric W. Biederman @ 2007-04-02 17:26 UTC (permalink / raw) To: vgoyal; +Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel Vivek Goyal <vgoyal@in.ibm.com> writes: > Only advantage of CONFIG_PHYSICAL_START seems to be that one has got > capability to run the kernel from other addresses without modifying the > boot-loader. One can argue that now people should use a relocatable kernel > for such a feature. But for using relocatable kenrel, one needs to modify > grub, lilo and I am not sure if somebody is going to do that. Secondly, how > would one specify an address to a boot-loader to load image at? I thought this was important for vmlinux and Xen? I guess at this point the easy case is that we modify /sbin/kexec to support it. And the other bootloaders can come be upgraded if the feature is interesting enough. > On i386, somebody already found an interesting usage of CONFIG_PHYSICAL_START > where he was running his kernel above 16MB so that he can maximize on > DMA ZONE. Can't think of any usage for x86_64 at the moment but I think > down the line people might come up with such usages. Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, although I admit that is a bit of a hack. > To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, > at the expense of reduced simplicity. We should definitely change the type > of vmlinux to ET_DYN but at the same time it might still be worth to retain > CONFIG_PHYSICAL_START option. I think something like CONFIG_PHYSICAL_START currently gives us very little gain, and is hard to use correctly, and there are alternative solutions. So if we can get rid of it, by only inconveniencing users who want load their kernels at a weird address it is worth it. >> I think I can switch the vmlinux header type in about 100 lines or so >> of code. Assuming I can ever get 30 minutes with the appropriate >> kernel. >> > > That would be awesome. Then vmlinux will be relocatable too. (Officially). Yes. For x86_64 I can do this. i386 is more difficult. (Although with a little cleverness we can move the code that processes relocations into vmlinux). Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-02 17:26 ` Eric W. Biederman @ 2007-04-03 4:01 ` Vivek Goyal 2007-04-03 5:23 ` Eric W. Biederman 0 siblings, 1 reply; 34+ messages in thread From: Vivek Goyal @ 2007-04-03 4:01 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel, Magnus Damm, Horms On Mon, Apr 02, 2007 at 11:26:38AM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > > Only advantage of CONFIG_PHYSICAL_START seems to be that one has got > > capability to run the kernel from other addresses without modifying the > > boot-loader. One can argue that now people should use a relocatable kernel > > for such a feature. But for using relocatable kenrel, one needs to modify > > grub, lilo and I am not sure if somebody is going to do that. Secondly, how > > would one specify an address to a boot-loader to load image at? > > I thought this was important for vmlinux and Xen? > Yes it is. Actually you had already mentioned it in the previous mail that's why I did not repeat it here. Xen folks wanted to continue using vmlinux for capturing dump. I am not sure if there is any technical limitation in using relocatable bzImage or just that they wanted to continue using existing working interface and did not want to switch to new interface. Magnus, Horms, do you want to add to it? Is there a reason that relocatable bzImage will not work in Xen env and we need to retain CONFIG_PHYSICAL_START option in x86_64? > I guess at this point the easy case is that we modify /sbin/kexec to support > it. And the other bootloaders can come be upgraded if the feature is > interesting enough. > > > On i386, somebody already found an interesting usage of CONFIG_PHYSICAL_START > > where he was running his kernel above 16MB so that he can maximize on > > DMA ZONE. Can't think of any usage for x86_64 at the moment but I think > > down the line people might come up with such usages. > > Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, > although I admit that is a bit of a hack. > Yes, but x86_64 will not have any of those options and only way to run kernel will be either use kexec or modify your boot-loader to so that it can handle relocatable images. > > To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, > > at the expense of reduced simplicity. We should definitely change the type > > of vmlinux to ET_DYN but at the same time it might still be worth to retain > > CONFIG_PHYSICAL_START option. > > I think something like CONFIG_PHYSICAL_START currently gives us very > little gain, and is hard to use correctly, and there are alternative > solutions. So if we can get rid of it, by only inconveniencing users > who want load their kernels at a weird address it is worth it. > > >> I think I can switch the vmlinux header type in about 100 lines or so > >> of code. Assuming I can ever get 30 minutes with the appropriate > >> kernel. > >> > > > > That would be awesome. Then vmlinux will be relocatable too. (Officially). > > Yes. For x86_64 I can do this. i386 is more difficult. (Although with > a little cleverness we can move the code that processes relocations into > vmlinux). > Performing relocations in vmlinux will be interesting. That way i386 vmlinux too will become relocatable and only piece of puzzle to solve will be to make vmlinux of type ET_DYN. Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-03 4:01 ` Vivek Goyal @ 2007-04-03 5:23 ` Eric W. Biederman 2007-04-03 10:03 ` Vivek Goyal 0 siblings, 1 reply; 34+ messages in thread From: Eric W. Biederman @ 2007-04-03 5:23 UTC (permalink / raw) To: vgoyal Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel, Magnus Damm, Horms Vivek Goyal <vgoyal@in.ibm.com> writes: >> I guess at this point the easy case is that we modify /sbin/kexec to support >> it. And the other bootloaders can come be upgraded if the feature is >> interesting enough. >> >> > On i386, somebody already found an interesting usage of > CONFIG_PHYSICAL_START >> > where he was running his kernel above 16MB so that he can maximize on >> > DMA ZONE. Can't think of any usage for x86_64 at the moment but I think >> > down the line people might come up with such usages. >> >> Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, >> although I admit that is a bit of a hack. >> > > Yes, but x86_64 will not have any of those options and only way to run > kernel will be either use kexec or modify your boot-loader to so that > it can handle relocatable images. True. >> > To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, >> > at the expense of reduced simplicity. We should definitely change the type >> > of vmlinux to ET_DYN but at the same time it might still be worth to retain >> > CONFIG_PHYSICAL_START option. >> >> I think something like CONFIG_PHYSICAL_START currently gives us very >> little gain, and is hard to use correctly, and there are alternative >> solutions. So if we can get rid of it, by only inconveniencing users >> who want load their kernels at a weird address it is worth it. >> >> >> I think I can switch the vmlinux header type in about 100 lines or so >> >> of code. Assuming I can ever get 30 minutes with the appropriate >> >> kernel. >> >> >> > >> > That would be awesome. Then vmlinux will be relocatable too. (Officially). >> >> Yes. For x86_64 I can do this. i386 is more difficult. (Although with >> a little cleverness we can move the code that processes relocations into >> vmlinux). >> > > Performing relocations in vmlinux will be interesting. That way i386 vmlinux > too will become relocatable and only piece of puzzle to solve will be to > make vmlinux of type ET_DYN. Actually making vmlinux have type ET_DYN is the easier piece. Basically the quick way to do this is to have an arch specific: "cmd_vmlinux__" like uml does so we can edit things after the make. Changing an integer in an ELF header is simple. Inserting the code to perform the relocations feels a bit trickier but we can probably just dump it in head.S like we do on x86_64. We still need to insert the actual relocations to process though. Which requires all of the post processing we currently do just called at a slightly different location. Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" 2007-04-03 5:23 ` Eric W. Biederman @ 2007-04-03 10:03 ` Vivek Goyal 2007-04-23 5:12 ` Eric W. Biederman 0 siblings, 1 reply; 34+ messages in thread From: Vivek Goyal @ 2007-04-03 10:03 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel, Magnus Damm, Horms On Mon, Apr 02, 2007 at 11:23:17PM -0600, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@in.ibm.com> writes: > > >> I guess at this point the easy case is that we modify /sbin/kexec to support > >> it. And the other bootloaders can come be upgraded if the feature is > >> interesting enough. > >> > >> > On i386, somebody already found an interesting usage of > > CONFIG_PHYSICAL_START > >> > where he was running his kernel above 16MB so that he can maximize on > >> > DMA ZONE. Can't think of any usage for x86_64 at the moment but I think > >> > down the line people might come up with such usages. > >> > >> Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, > >> although I admit that is a bit of a hack. > >> > > > > Yes, but x86_64 will not have any of those options and only way to run > > kernel will be either use kexec or modify your boot-loader to so that > > it can handle relocatable images. > > True. > > >> > To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, > >> > at the expense of reduced simplicity. We should definitely change the type > >> > of vmlinux to ET_DYN but at the same time it might still be worth to retain > >> > CONFIG_PHYSICAL_START option. > >> > >> I think something like CONFIG_PHYSICAL_START currently gives us very > >> little gain, and is hard to use correctly, and there are alternative > >> solutions. So if we can get rid of it, by only inconveniencing users > >> who want load their kernels at a weird address it is worth it. > >> > >> >> I think I can switch the vmlinux header type in about 100 lines or so > >> >> of code. Assuming I can ever get 30 minutes with the appropriate > >> >> kernel. > >> >> > >> > > >> > That would be awesome. Then vmlinux will be relocatable too. (Officially). > >> > >> Yes. For x86_64 I can do this. i386 is more difficult. (Although with > >> a little cleverness we can move the code that processes relocations into > >> vmlinux). > >> > > > > Performing relocations in vmlinux will be interesting. That way i386 vmlinux > > too will become relocatable and only piece of puzzle to solve will be to > > make vmlinux of type ET_DYN. > > Actually making vmlinux have type ET_DYN is the easier piece. Basically > the quick way to do this is to have an arch specific: "cmd_vmlinux__" > like uml does so we can edit things after the make. > > Changing an integer in an ELF header is simple. > > Inserting the code to perform the relocations feels a bit trickier but > we can probably just dump it in head.S like we do on x86_64. We still need > to insert the actual relocations to process though. Which requires all of the > post processing we currently do just called at a slightly different location. Something like what kallsyms does? Read .tmp_vmlinux2, extract and filter relocations, pack them in relocs.S, build reloc.o and relink it back to .tmp_vmlinux2 to make vmlinux. Then arch/i386/kernel/head.S can perform the relocations. But any additiona step of re-linking after final kallsyms information has been generated can potentially spoil kallsyms data? Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-04-03 10:03 ` Vivek Goyal @ 2007-04-23 5:12 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-23 5:12 UTC (permalink / raw) To: Andrew Morton, Andi Kleen Cc: vgoyal, Jurriaan, Helge Hafting, linux-kernel, Magnus Damm, Horms, thunder7, fastboot, Kexec Mailing List Currently because vmlinux does not reflect that the kernel is relocatable we still have to support CONFIG_PHYSICAL_START. So this patch adds a small c program to do what we cannot do with a linker script, set the elf header type to ET_DYN. This should remove the last obstacle to removing CONFIG_PHYSICAL_START on x86_64. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86_64/Kconfig | 4 +++ arch/x86_64/Makefile | 10 +++++++ scripts/Makefile | 11 ++++--- scripts/mketrel.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 5 deletions(-) create mode 100644 scripts/mketrel.c diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 16d9bf3..773b487 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ELF_RELOCATABLE + bool + default y + source "init/Kconfig" diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index 9dd91b2..5ae79ab 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -124,6 +124,16 @@ define archhelp echo ' isoimage - Create a boot CD-ROM image' endef +ifeq ($(CONFIG_RELOCATABLE),y) +define cmd_vmlinux__ + $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ + -T $(vmlinux-lds) $(vmlinux-init) \ + --start-group $(vmlinux-main) --end-group \ + $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \ + && scripts/mketrel $@ +endef +endif + CLEAN_FILES += arch/$(ARCH)/boot/fdimage \ arch/$(ARCH)/boot/image.iso \ arch/$(ARCH)/boot/mtools.conf diff --git a/scripts/Makefile b/scripts/Makefile index 1c73c5a..ddba550 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -7,11 +7,12 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables -hostprogs-$(CONFIG_KALLSYMS) += kallsyms -hostprogs-$(CONFIG_LOGO) += pnmtologo -hostprogs-$(CONFIG_VT) += conmakehash -hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash -hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_KALLSYMS) += kallsyms +hostprogs-$(CONFIG_LOGO) += pnmtologo +hostprogs-$(CONFIG_VT) += conmakehash +hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash +hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel always := $(hostprogs-y) $(hostprogs-m) diff --git a/scripts/mketrel.c b/scripts/mketrel.c new file mode 100644 index 0000000..effa312 --- /dev/null +++ b/scripts/mketrel.c @@ -0,0 +1,70 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <unistd.h> +#include <elf.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdarg.h> +#include <stdlib.h> + +static int fd; +unsigned char e_ident[EI_NIDENT]; + +void die(const char * str, ...) +{ + va_list args; + va_start(args, str); + vfprintf(stderr, str, args); + fputc('\n', stderr); + exit(1); +} + +void file_open(const char *name) +{ + if ((fd = open(name, O_RDWR, 0)) < 0) + die("Unable to open `%s': %m", name); +} + +static void mketrel(void) +{ + unsigned char e_type[2]; + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) + die("Cannot read ELF header: %s\n", strerror(errno)); + + if (memcmp(e_ident, ELFMAG, 4) != 0) + die("No ELF magic\n"); + + if ((e_ident[EI_CLASS] != ELFCLASS64) && + (e_ident[EI_CLASS] != ELFCLASS32)) + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); + + if ((e_ident[EI_DATA] != ELFDATA2LSB) && + (e_ident[EI_DATA] != ELFDATA2MSB)) + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); + + if (e_ident[EI_VERSION] != EV_CURRENT) + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); + + if (e_ident[EI_DATA] == ELFDATA2LSB) { + e_type[0] = ET_REL & 0xff; + e_type[1] = ET_REL >> 8; + } else { + e_type[1] = ET_REL & 0xff; + e_type[0] = ET_REL >> 8; + } + + if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type)) + die("Cannot write ELF type: %s\n", strerror(errno)); +} + +int main(int argc, char **argv) +{ + if (argc != 2) + die("Usage: mketrel: vmlinux"); + file_open(argv[1]); + mketrel(); + close(fd); + return 0; +} -- 1.5.1.1.181.g2de0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-23 5:12 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-23 5:12 UTC (permalink / raw) To: Andrew Morton, Andi Kleen Cc: fastboot, Horms, linux-kernel, Kexec Mailing List, Helge Hafting, thunder7, Magnus Damm, vgoyal Currently because vmlinux does not reflect that the kernel is relocatable we still have to support CONFIG_PHYSICAL_START. So this patch adds a small c program to do what we cannot do with a linker script, set the elf header type to ET_DYN. This should remove the last obstacle to removing CONFIG_PHYSICAL_START on x86_64. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86_64/Kconfig | 4 +++ arch/x86_64/Makefile | 10 +++++++ scripts/Makefile | 11 ++++--- scripts/mketrel.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 5 deletions(-) create mode 100644 scripts/mketrel.c diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 16d9bf3..773b487 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ELF_RELOCATABLE + bool + default y + source "init/Kconfig" diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index 9dd91b2..5ae79ab 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -124,6 +124,16 @@ define archhelp echo ' isoimage - Create a boot CD-ROM image' endef +ifeq ($(CONFIG_RELOCATABLE),y) +define cmd_vmlinux__ + $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ + -T $(vmlinux-lds) $(vmlinux-init) \ + --start-group $(vmlinux-main) --end-group \ + $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \ + && scripts/mketrel $@ +endef +endif + CLEAN_FILES += arch/$(ARCH)/boot/fdimage \ arch/$(ARCH)/boot/image.iso \ arch/$(ARCH)/boot/mtools.conf diff --git a/scripts/Makefile b/scripts/Makefile index 1c73c5a..ddba550 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -7,11 +7,12 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables -hostprogs-$(CONFIG_KALLSYMS) += kallsyms -hostprogs-$(CONFIG_LOGO) += pnmtologo -hostprogs-$(CONFIG_VT) += conmakehash -hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash -hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_KALLSYMS) += kallsyms +hostprogs-$(CONFIG_LOGO) += pnmtologo +hostprogs-$(CONFIG_VT) += conmakehash +hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash +hostprogs-$(CONFIG_IKCONFIG) += bin2c +hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel always := $(hostprogs-y) $(hostprogs-m) diff --git a/scripts/mketrel.c b/scripts/mketrel.c new file mode 100644 index 0000000..effa312 --- /dev/null +++ b/scripts/mketrel.c @@ -0,0 +1,70 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <unistd.h> +#include <elf.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdarg.h> +#include <stdlib.h> + +static int fd; +unsigned char e_ident[EI_NIDENT]; + +void die(const char * str, ...) +{ + va_list args; + va_start(args, str); + vfprintf(stderr, str, args); + fputc('\n', stderr); + exit(1); +} + +void file_open(const char *name) +{ + if ((fd = open(name, O_RDWR, 0)) < 0) + die("Unable to open `%s': %m", name); +} + +static void mketrel(void) +{ + unsigned char e_type[2]; + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) + die("Cannot read ELF header: %s\n", strerror(errno)); + + if (memcmp(e_ident, ELFMAG, 4) != 0) + die("No ELF magic\n"); + + if ((e_ident[EI_CLASS] != ELFCLASS64) && + (e_ident[EI_CLASS] != ELFCLASS32)) + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); + + if ((e_ident[EI_DATA] != ELFDATA2LSB) && + (e_ident[EI_DATA] != ELFDATA2MSB)) + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); + + if (e_ident[EI_VERSION] != EV_CURRENT) + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); + + if (e_ident[EI_DATA] == ELFDATA2LSB) { + e_type[0] = ET_REL & 0xff; + e_type[1] = ET_REL >> 8; + } else { + e_type[1] = ET_REL & 0xff; + e_type[0] = ET_REL >> 8; + } + + if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type)) + die("Cannot write ELF type: %s\n", strerror(errno)); +} + +int main(int argc, char **argv) +{ + if (argc != 2) + die("Usage: mketrel: vmlinux"); + file_open(argv[1]); + mketrel(); + close(fd); + return 0; +} -- 1.5.1.1.181.g2de0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-04-23 5:12 ` Eric W. Biederman @ 2007-04-24 6:31 ` Vivek Goyal -1 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-04-24 6:31 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, Andi Kleen, Jurriaan, Helge Hafting, linux-kernel, Horms, Kexec Mailing List On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote: > > Currently because vmlinux does not reflect that the kernel is relocatable > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > c program to do what we cannot do with a linker script, set the elf header > type to ET_DYN. > > This should remove the last obstacle to removing CONFIG_PHYSICAL_START > on x86_64. > > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> [Dropping fastboot mailing list from CC as kexec mailing list is new list for this discussion] [..] > +void file_open(const char *name) > +{ > + if ((fd = open(name, O_RDWR, 0)) < 0) > + die("Unable to open `%s': %m", name); > +} > + > +static void mketrel(void) > +{ > + unsigned char e_type[2]; > + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) > + die("Cannot read ELF header: %s\n", strerror(errno)); > + > + if (memcmp(e_ident, ELFMAG, 4) != 0) > + die("No ELF magic\n"); > + > + if ((e_ident[EI_CLASS] != ELFCLASS64) && > + (e_ident[EI_CLASS] != ELFCLASS32)) > + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); > + > + if ((e_ident[EI_DATA] != ELFDATA2LSB) && > + (e_ident[EI_DATA] != ELFDATA2MSB)) > + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); > + > + if (e_ident[EI_VERSION] != EV_CURRENT) > + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); > + > + if (e_ident[EI_DATA] == ELFDATA2LSB) { > + e_type[0] = ET_REL & 0xff; > + e_type[1] = ET_REL >> 8; > + } else { > + e_type[1] = ET_REL & 0xff; > + e_type[0] = ET_REL >> 8; > + } Hi Eric, Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux as it does not find it to be executable type. I am not well versed with various conventions but if I go through "Executable and Linking Format" document, this is what it says about various file types. • A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file. • An executable file holds a program suitable for execution. • A shared object file holds code and data suitable for linking in two contexts. First, the link editor may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image. So above does not seem to fit in the ET_REL type. We can't relink this vmlinux? And it does not seem to fit in ET_DYN definition too. We are not relinking this vmlinux with another executable or other relocatable files. I remember once you mentioned the term dynamic executable which can be loaded at a non-compiled address and let run without requiring any relocation processing. This vmlinux will fall in that category but can't relate it to standard elf file definitions. Thanks Vivek ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-24 6:31 ` Vivek Goyal 0 siblings, 0 replies; 34+ messages in thread From: Vivek Goyal @ 2007-04-24 6:31 UTC (permalink / raw) To: Eric W. Biederman Cc: Kexec Mailing List, Jurriaan, linux-kernel, Andi Kleen, Helge Hafting, Horms, Andrew Morton On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote: > > Currently because vmlinux does not reflect that the kernel is relocatable > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > c program to do what we cannot do with a linker script, set the elf header > type to ET_DYN. > > This should remove the last obstacle to removing CONFIG_PHYSICAL_START > on x86_64. > > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> [Dropping fastboot mailing list from CC as kexec mailing list is new list for this discussion] [..] > +void file_open(const char *name) > +{ > + if ((fd = open(name, O_RDWR, 0)) < 0) > + die("Unable to open `%s': %m", name); > +} > + > +static void mketrel(void) > +{ > + unsigned char e_type[2]; > + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) > + die("Cannot read ELF header: %s\n", strerror(errno)); > + > + if (memcmp(e_ident, ELFMAG, 4) != 0) > + die("No ELF magic\n"); > + > + if ((e_ident[EI_CLASS] != ELFCLASS64) && > + (e_ident[EI_CLASS] != ELFCLASS32)) > + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); > + > + if ((e_ident[EI_DATA] != ELFDATA2LSB) && > + (e_ident[EI_DATA] != ELFDATA2MSB)) > + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); > + > + if (e_ident[EI_VERSION] != EV_CURRENT) > + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); > + > + if (e_ident[EI_DATA] == ELFDATA2LSB) { > + e_type[0] = ET_REL & 0xff; > + e_type[1] = ET_REL >> 8; > + } else { > + e_type[1] = ET_REL & 0xff; > + e_type[0] = ET_REL >> 8; > + } Hi Eric, Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux as it does not find it to be executable type. I am not well versed with various conventions but if I go through "Executable and Linking Format" document, this is what it says about various file types. • A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file. • An executable file holds a program suitable for execution. • A shared object file holds code and data suitable for linking in two contexts. First, the link editor may process it with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image. So above does not seem to fit in the ET_REL type. We can't relink this vmlinux? And it does not seem to fit in ET_DYN definition too. We are not relinking this vmlinux with another executable or other relocatable files. I remember once you mentioned the term dynamic executable which can be loaded at a non-compiled address and let run without requiring any relocation processing. This vmlinux will fall in that category but can't relate it to standard elf file definitions. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. 2007-04-24 6:31 ` Vivek Goyal @ 2007-04-24 7:21 ` Eric W. Biederman -1 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-24 7:21 UTC (permalink / raw) To: vgoyal Cc: Andrew Morton, Andi Kleen, Jurriaan, Helge Hafting, linux-kernel, Horms, Kexec Mailing List Vivek Goyal <vgoyal@in.ibm.com> writes: > On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote: >> >> Currently because vmlinux does not reflect that the kernel is relocatable >> we still have to support CONFIG_PHYSICAL_START. So this patch adds a small >> c program to do what we cannot do with a linker script, set the elf header >> type to ET_DYN. >> >> This should remove the last obstacle to removing CONFIG_PHYSICAL_START >> on x86_64. >> >> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> > > [Dropping fastboot mailing list from CC as kexec mailing list is new list > for this discussion] > > [..] >> +void file_open(const char *name) >> +{ >> + if ((fd = open(name, O_RDWR, 0)) < 0) >> + die("Unable to open `%s': %m", name); >> +} >> + >> +static void mketrel(void) >> +{ >> + unsigned char e_type[2]; >> + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) >> + die("Cannot read ELF header: %s\n", strerror(errno)); >> + >> + if (memcmp(e_ident, ELFMAG, 4) != 0) >> + die("No ELF magic\n"); >> + >> + if ((e_ident[EI_CLASS] != ELFCLASS64) && >> + (e_ident[EI_CLASS] != ELFCLASS32)) >> + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); >> + >> + if ((e_ident[EI_DATA] != ELFDATA2LSB) && >> + (e_ident[EI_DATA] != ELFDATA2MSB)) >> + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); >> + >> + if (e_ident[EI_VERSION] != EV_CURRENT) >> + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); >> + >> + if (e_ident[EI_DATA] == ELFDATA2LSB) { >> + e_type[0] = ET_REL & 0xff; >> + e_type[1] = ET_REL >> 8; >> + } else { >> + e_type[1] = ET_REL & 0xff; >> + e_type[0] = ET_REL >> 8; >> + } > > Hi Eric, > > Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux > as it does not find it to be executable type. Doh. It should be ET_DYN. I had relocatable much to much on the brain, and so I stuffed in the wrong type. > I am not well versed with various conventions but if I go through "Executable > and Linking Format" document, this is what it says about various file types. > > • A relocatable file holds code and data suitable for linking with other > object files to create an executable or a shared object file. > > • An executable file holds a program suitable for execution. > > • A shared object file holds code and data suitable for linking in two > contexts. First, the link editor may process it with other relocatable and > shared object files to create another object file. Second, the dynamic > linker combines it with an executable file and other shared objects > to create a process image. > > So above does not seem to fit in the ET_REL type. We can't relink this > vmlinux? And it does not seem to fit in ET_DYN definition too. We are > not relinking this vmlinux with another executable or other relocatable > files. > > I remember once you mentioned the term dynamic executable which can be > loaded at a non-compiled address and let run without requiring any > relocation processing. This vmlinux will fall in that category but can't > relate it to standard elf file definitions. Sorry about that. ET_DYN without a PT_DYNAMIC segment, without a PT_INTERP segment, and with a valid entry point is exactly that. Loaders never perform relocation processing on a ET_DYN executable but they are allowed to shift all of the addresses by a single delta so long as all of the alignment restrictions are honored. Relocation processing when it happens comes from the dynamic linker, which is set in PT_INTERP and the dynamic linker looks a PT_DYNAMIC to figure out what relocations are available for processing. The basic issue is that ld don't really comprehend what we are doing since we are building a position independent executable in a way that the normal tools don't allow, so we have to poke the header. If we had compiled with -fPIC we could have specified -pie or --pic-executable to ld and it would have done the right thing. But as it is our executable only changes physical addresses and not virtual addresses something completely foreign to ld. Eric ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header. @ 2007-04-24 7:21 ` Eric W. Biederman 0 siblings, 0 replies; 34+ messages in thread From: Eric W. Biederman @ 2007-04-24 7:21 UTC (permalink / raw) To: vgoyal Cc: Kexec Mailing List, Jurriaan, linux-kernel, Andi Kleen, Helge Hafting, Horms, Andrew Morton [-- Attachment #1: Type: text/plain, Size: 4202 bytes --] Vivek Goyal <vgoyal@in.ibm.com> writes: > On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote: >> >> Currently because vmlinux does not reflect that the kernel is relocatable >> we still have to support CONFIG_PHYSICAL_START. So this patch adds a small >> c program to do what we cannot do with a linker script, set the elf header >> type to ET_DYN. >> >> This should remove the last obstacle to removing CONFIG_PHYSICAL_START >> on x86_64. >> >> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> > > [Dropping fastboot mailing list from CC as kexec mailing list is new list > for this discussion] > > [..] >> +void file_open(const char *name) >> +{ >> + if ((fd = open(name, O_RDWR, 0)) < 0) >> + die("Unable to open `%s': %m", name); >> +} >> + >> +static void mketrel(void) >> +{ >> + unsigned char e_type[2]; >> + if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident)) >> + die("Cannot read ELF header: %s\n", strerror(errno)); >> + >> + if (memcmp(e_ident, ELFMAG, 4) != 0) >> + die("No ELF magic\n"); >> + >> + if ((e_ident[EI_CLASS] != ELFCLASS64) && >> + (e_ident[EI_CLASS] != ELFCLASS32)) >> + die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]); >> + >> + if ((e_ident[EI_DATA] != ELFDATA2LSB) && >> + (e_ident[EI_DATA] != ELFDATA2MSB)) >> + die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]); >> + >> + if (e_ident[EI_VERSION] != EV_CURRENT) >> + die("Unknown ELF version: %d\n", e_ident[EI_VERSION]); >> + >> + if (e_ident[EI_DATA] == ELFDATA2LSB) { >> + e_type[0] = ET_REL & 0xff; >> + e_type[1] = ET_REL >> 8; >> + } else { >> + e_type[1] = ET_REL & 0xff; >> + e_type[0] = ET_REL >> 8; >> + } > > Hi Eric, > > Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux > as it does not find it to be executable type. Doh. It should be ET_DYN. I had relocatable much to much on the brain, and so I stuffed in the wrong type. > I am not well versed with various conventions but if I go through "Executable > and Linking Format" document, this is what it says about various file types. > > • A relocatable file holds code and data suitable for linking with other > object files to create an executable or a shared object file. > > • An executable file holds a program suitable for execution. > > • A shared object file holds code and data suitable for linking in two > contexts. First, the link editor may process it with other relocatable and > shared object files to create another object file. Second, the dynamic > linker combines it with an executable file and other shared objects > to create a process image. > > So above does not seem to fit in the ET_REL type. We can't relink this > vmlinux? And it does not seem to fit in ET_DYN definition too. We are > not relinking this vmlinux with another executable or other relocatable > files. > > I remember once you mentioned the term dynamic executable which can be > loaded at a non-compiled address and let run without requiring any > relocation processing. This vmlinux will fall in that category but can't > relate it to standard elf file definitions. Sorry about that. ET_DYN without a PT_DYNAMIC segment, without a PT_INTERP segment, and with a valid entry point is exactly that. Loaders never perform relocation processing on a ET_DYN executable but they are allowed to shift all of the addresses by a single delta so long as all of the alignment restrictions are honored. Relocation processing when it happens comes from the dynamic linker, which is set in PT_INTERP and the dynamic linker looks a PT_DYNAMIC to figure out what relocations are available for processing. The basic issue is that ld don't really comprehend what we are doing since we are building a position independent executable in a way that the normal tools don't allow, so we have to poke the header. If we had compiled with -fPIC we could have specified -pie or --pic-executable to ld and it would have done the right thing. But as it is our executable only changes physical addresses and not virtual addresses something completely foreign to ld. Eric [-- Attachment #2: Type: text/plain, Size: 143 bytes --] _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2007-06-01 12:26 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-30 15:12 [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman 2007-04-30 15:12 ` Eric W. Biederman 2007-04-30 15:17 ` Andi Kleen 2007-04-30 15:17 ` Andi Kleen 2007-05-01 3:55 ` Vivek Goyal 2007-05-01 3:55 ` Vivek Goyal 2007-05-01 4:20 ` Eric W. Biederman 2007-05-01 4:20 ` Eric W. Biederman 2007-05-01 5:06 ` Vivek Goyal 2007-05-01 5:06 ` Vivek Goyal 2007-05-01 5:26 ` Eric W. Biederman 2007-05-01 5:26 ` Eric W. Biederman 2007-05-01 6:25 ` Andi Kleen 2007-05-01 6:25 ` Andi Kleen 2007-05-01 5:54 ` Eric W. Biederman 2007-05-01 5:54 ` Eric W. Biederman 2007-05-01 6:44 ` Vivek Goyal 2007-05-01 6:44 ` Vivek Goyal 2007-05-28 10:54 ` Bernhard Walle 2007-05-28 10:54 ` Bernhard Walle 2007-05-28 11:09 ` Vivek Goyal 2007-05-28 11:09 ` Vivek Goyal 2007-05-28 14:39 ` Bernhard Walle 2007-05-28 14:39 ` Bernhard Walle 2007-06-01 12:26 ` Bernhard Walle 2007-06-01 12:26 ` Bernhard Walle 2007-05-28 14:57 ` Andi Kleen 2007-05-28 14:57 ` Andi Kleen -- strict thread matches above, loose matches on Subject: below -- 2007-03-31 7:53 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Andrew Morton 2007-04-01 5:29 ` thunder7 2007-04-01 6:15 ` Eric W. Biederman 2007-04-01 6:29 ` Andrew Morton 2007-04-02 7:41 ` Vivek Goyal 2007-04-02 8:43 ` Eric W. Biederman 2007-04-02 9:45 ` Vivek Goyal 2007-04-02 17:26 ` Eric W. Biederman 2007-04-03 4:01 ` Vivek Goyal 2007-04-03 5:23 ` Eric W. Biederman 2007-04-03 10:03 ` Vivek Goyal 2007-04-23 5:12 ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman 2007-04-23 5:12 ` Eric W. Biederman 2007-04-24 6:31 ` Vivek Goyal 2007-04-24 6:31 ` Vivek Goyal 2007-04-24 7:21 ` Eric W. Biederman 2007-04-24 7:21 ` Eric W. Biederman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.