Re: kexec -p loads
On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote: Hi Vivek, I'm having trouble getting a system kernel to load a kdump kernel. These are 2.6.26.2 kernels on an x86_64. The kdump kernel has no modules. The kdump kernel area is reserved as [EMAIL PROTECTED] This is the way I try to load it: /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append=root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices This works with -l. But with -p the kernel objects to the 2 lowest segments, at 0x1000 and 0xa000 which I presume are the startup code and arguments. CCing to kexec mailing list. Few questions. - What version of kexec-tools are you using? - Can you please provide output of /proc/iomem. (With crash kernel memory reserved). - Looks like you have compiled your kernel for physical address 16MB? (CONFIG_PHYSICAL_START=0x100) - Can you also try loading relocatable bzImage, instead of vmlinux and see what happens. I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. For crash kernels, kexec-tools sets the value of mem-min and mem-max in such a manner that it is with-in reserved memory area so that any memory allocation in locate_hole() is done with-in reserved area and not outside it. In your case looks like something went wrong. Either memory area was not reserved properly or value of mem-min, mem-max was not set properly etc. Can you please paste the output of /proc/iomem and also do some kexec-tools debugging. Especially value of mem-max and mem-min inside locate_hole() function. Thanks Vivek segment[2].buf = 0x7f9bd8461010 segment[2].bufsz = 224668 segment[2].mem = 0x100 segment[2].memsz = 225000 segment[3].buf = 0x7f9bd8686010 segment[3].bufsz = 75508 segment[3].mem = 0x1225000 segment[3].memsz = 76000 segment[4].buf = 0x7f9bd8761010 segment[4].bufsz = c08 segment[4].mem = 0x129b000 segment[4].memsz = 1000 segment[5].buf = 0x7f9bd87fd010 segment[5].bufsz = 30004 segment[5].mem = 0x129c000 segment[5].memsz = c2000 kexec_load failed: Cannot assign requested address And I have some debugging in the system kernel: cleopatra1:/tmp/cpw # dmesg | tail cpw: -p, call kimage_crash_alloc cpw: kimage_crash_alloc bad entry point 0x1550:0x100 0x1550:0x4ff cpw: kimage_crash_alloc segment 0: 0x1000-0x9fff cpw: kimage_crash_alloc pta EADDRNOTAVAIL 0x1000:0x100 0x9fff:0x4ff cpw: kimage_crash_alloc segment 1: 0xa000-0xafff cpw: kimage_crash_alloc pta EADDRNOTAVAIL 0xa000:0x100 0xafff:0x4ff cpw: kimage_crash_alloc segment 2: 0x100-0x1224fff cpw: kimage_crash_alloc segment 3: 0x1225000-0x129afff cpw: kimage_crash_alloc segment 4: 0x129b000-0x129bfff cpw: kimage_crash_alloc segment 5: 0x129c000-0x135dfff The code that insists that the entry point must be within [EMAIL PROTECTED], and that every segment must also be in that range, seems to be old code. I don't understand. Is kexec generating bad segments? Or am I mis-using something? Can you tell from the above? Thanks. -Cliff ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
* Vivek Goyal [2008-08-27 09:39]: On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote: Hi Vivek, I'm having trouble getting a system kernel to load a kdump kernel. These are 2.6.26.2 kernels on an x86_64. The kdump kernel has no modules. The kdump kernel area is reserved as [EMAIL PROTECTED] This is the way I try to load it: /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append=root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices This works with -l. But with -p the kernel objects to the 2 lowest segments, at 0x1000 and 0xa000 which I presume are the startup code and arguments. CCing to kexec mailing list. Few questions. - What version of kexec-tools are you using? - Can you please provide output of /proc/iomem. (With crash kernel memory reserved). - Looks like you have compiled your kernel for physical address 16MB? (CONFIG_PHYSICAL_START=0x100) - Can you also try loading relocatable bzImage, instead of vmlinux and see what happens. I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
On Wed, Aug 27, 2008 at 03:43:33PM +0200, Bernhard Walle wrote: * Vivek Goyal [2008-08-27 09:39]: On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote: Hi Vivek, I'm having trouble getting a system kernel to load a kdump kernel. These are 2.6.26.2 kernels on an x86_64. The kdump kernel has no modules. The kdump kernel area is reserved as [EMAIL PROTECTED] This is the way I try to load it: /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append=root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices This works with -l. But with -p the kernel objects to the 2 lowest segments, at 0x1000 and 0xa000 which I presume are the startup code and arguments. CCing to kexec mailing list. Few questions. - What version of kexec-tools are you using? - Can you please provide output of /proc/iomem. (With crash kernel memory reserved). - Looks like you have compiled your kernel for physical address 16MB? (CONFIG_PHYSICAL_START=0x100) - Can you also try loading relocatable bzImage, instead of vmlinux and see what happens. I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. True that vmlinux is not relocatable. But one can always compile the vmlinux for a fixed physical address (Address in reserved region) and then use it? In this case his vmlinux seems to have been compiled for physical address 16MB. Which should be usable if there is a reserved memory region at 16MB. Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
* Vivek Goyal [2008-08-27 11:28]: I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. True that vmlinux is not relocatable. But one can always compile the vmlinux for a fixed physical address (Address in reserved region) and then use it? In this case his vmlinux seems to have been compiled for physical address 16MB. Which should be usable if there is a reserved memory region at 16MB. Of course, that's true. I just thought when Cliff uses the same kernel for kexec -l and kexec -p, then it's the normal kernel. But I didn't calculate the numbers. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote: * Vivek Goyal [2008-08-27 11:28]: I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. True that vmlinux is not relocatable. But one can always compile the vmlinux for a fixed physical address (Address in reserved region) and then use it? In this case his vmlinux seems to have been compiled for physical address 16MB. Which should be usable if there is a reserved memory region at 16MB. Of course, that's true. I just thought when Cliff uses the same kernel for kexec -l and kexec -p, then it's the normal kernel. But I didn't calculate the numbers. Its litle tricky. I think one can always do both kexec -l and kexec -p on a vmlinux which has been built for kdump (for reserved region). But one can not do kexec -p on normal kernel vmlinux. So I am assuming that Cliff is running into first case. But he can tell us more. Cliff, is it same vmlinux which you use for first kernel or a different vmlinux compiled for dump capture. Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
On Wed, Aug 27, 2008 at 01:34:13PM -0500, Cliff Wickman wrote: On Wed, Aug 27, 2008 at 11:36:22AM -0400, Vivek Goyal wrote: On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote: * Vivek Goyal [2008-08-27 11:28]: I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. True that vmlinux is not relocatable. But one can always compile the vmlinux for a fixed physical address (Address in reserved region) and then use it? In this case his vmlinux seems to have been compiled for physical address 16MB. Which should be usable if there is a reserved memory region at 16MB. Of course, that's true. I just thought when Cliff uses the same kernel for kexec -l and kexec -p, then it's the normal kernel. But I didn't calculate the numbers. Its litle tricky. I think one can always do both kexec -l and kexec -p on a vmlinux which has been built for kdump (for reserved region). But one can not do kexec -p on normal kernel vmlinux. So I am assuming that Cliff is running into first case. But he can tell us more. Cliff, is it same vmlinux which you use for first kernel or a different vmlinux compiled for dump capture. Sorry for the lag. I was working on the problem and not watching my mail. I'm using two different kernels. The kdump vmlinux is compiled with CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x100 I'm using kexec-tools-1.101 This is too old a version. Can you try the version 2.0.0. from following link. http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.bz2 Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec -p loads
On Wed, Aug 27, 2008 at 03:01:57PM -0400, Vivek Goyal wrote: On Wed, Aug 27, 2008 at 01:34:13PM -0500, Cliff Wickman wrote: On Wed, Aug 27, 2008 at 11:36:22AM -0400, Vivek Goyal wrote: On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote: * Vivek Goyal [2008-08-27 11:28]: I have this debugging output from my kexec: cpw: elf_x86_64_load returning entry:0x1550 cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550 kexec_load: entry = 0x1550 flags = 1 nr_segments = 6 segment[0].buf = 0x5237a0 segment[0].bufsz = 7100 segment[0].mem = 0x1000 segment[0].memsz = 9000 segment[1].buf = 0x52aaf0 segment[1].bufsz = 1000 segment[1].mem = 0xa000 segment[1].memsz = 1000 I think above two segments are not being loaded at right place. Looks like kexec-tools decided to load first one at physical address 0x1000 and other at physical address 0xa000. For crash kernel this is not right. It should come out of reserved memory area and that's why you are encountering the error. Relocatability in ELF image never worked on x86_64 because of GDB but (so the binary was marked as ET_EXEC instead of ET_DYN). You have to use bzImage for kdump in any case. True that vmlinux is not relocatable. But one can always compile the vmlinux for a fixed physical address (Address in reserved region) and then use it? In this case his vmlinux seems to have been compiled for physical address 16MB. Which should be usable if there is a reserved memory region at 16MB. Of course, that's true. I just thought when Cliff uses the same kernel for kexec -l and kexec -p, then it's the normal kernel. But I didn't calculate the numbers. Its litle tricky. I think one can always do both kexec -l and kexec -p on a vmlinux which has been built for kdump (for reserved region). But one can not do kexec -p on normal kernel vmlinux. So I am assuming that Cliff is running into first case. But he can tell us more. Cliff, is it same vmlinux which you use for first kernel or a different vmlinux compiled for dump capture. Sorry for the lag. I was working on the problem and not watching my mail. I'm using two different kernels. The kdump vmlinux is compiled with CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x100 I'm using kexec-tools-1.101 This is too old a version. Can you try the version 2.0.0. from following link. http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.bz2 Ahh. That works. I think I got 1.101 as the latest from sourceforge. I should've looked at the path in Documentation/kdump/kdump.txt Thanks. -Cliff -- Cliff Wickman Silicon Graphics, Inc. [EMAIL PROTECTED] (651) 683-3824 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
