lkml.org 
[lkml]   [2006]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.19-rc1: kexec broken on x86_64
Date
Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Thu, Oct 05, 2006 at 10:56:51PM +0900, Magnus Damm wrote:
>> Hi Vivek,
>>
>> On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>> >On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
>> >> Kexec is broken on x86_64 under 2.6.19-rc1.
>> >>
>> >> Or rather - kexec works ok under 2.6.19-rc1, but something related to
>> >> the vmlinux format has probably changed and kexec-tools fails to load
>> >> a vmlinux from 2.6.19-rc1.
>> >>
>> >> Loading bzImage works as usual, but vmlinux does not load properly.
>> >>
>> >> The kexec binary fails with the following message:
>> >>
>> >> Overlapping memory segments at 0x351000
>> >> sort_segments failed
>> >> / #
>> >>
>> >
>> >Hi Magnus,
>> >
>> >Can you please post the readelf -l output of the vmlinux you are trying
>> >to load. That's will give some indication if the segments are really
>> >overlapping in vmlinux or is it some processing bug at kexec-tools part.
>>
>> Elf file type is EXEC (Executable file)
>> Entry point 0x100100
>> There are 4 program headers, starting at offset 64
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr
>> FileSiz MemSiz Flags Align
>> LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
>> 0x00000000001a4888 0x00000000001a4888 R E 100000
>> LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
>> 0x000000000008e086 0x00000000000c1504 RWE 100000
>> LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
>> 0x0000000000000c08 0x0000000000000c08 RWE 100000
>> NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> 0x0000000000000000 0x0000000000000000 R 8
>>
>> Section to Segment mapping:
>> Segment Sections...
>> 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
>> __ksymtab_unused __ksymtab_strings __param
>> 01 .data .data.cacheline_aligned .data.read_mostly
>> .data.init_task .data.page_aligned .init.text .init.data .init.setup
>> .initcall.init .con_initcall.init .altinstructions
>> .altinstr_replacement .exit.text .init.ramfs .bss
>> 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
>> .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
>> 03
>>
>
> Ok. So second and third program header are overlapping in physical
> address space and that's why kexec-tools is cribbing.
>
> Looking at these headers, it looks like program header 02 which contains
> will overwrite some of the data of program header 01 and I think that's
> wrong. Will look more into it.

Ack. I forgot to check the lengths...
That last segment (which I presume is the vdso) is quite short.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-05 17:23    [W:0.058 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site