Hi Jay, The attacked patch fixes the problem. Please try. diff -Nurp kexec-tools-1.101.org/kexec/arch/ia64/crashdump-ia64.c kexec-tools-1.101/kexec/arch/ia64/crashdump-ia64.c --- kexec-tools-1.101.org/kexec/arch/ia64/crashdump-ia64.c 2006-11-09 19:40:52.000000000 +0900 +++ kexec-tools-1.101/kexec/arch/ia64/crashdump-ia64.c 2006-11-13 19:17:15.000000000 +0900 @@ -316,9 +316,13 @@ int load_crashdump_segments(struct kexec int nr_ranges; size_t size; void *tmp; + long int nr_cpus = 0; + if ((nr_cpus = sysconf(_SC_NPROCESSORS_CONF)) < 0) + return -1; if (info->kexec_flags & KEXEC_ON_CRASH ) { if (get_crash_memory_ranges(&mem_range, &nr_ranges) == 0) { size = sizeof(Elf64_Ehdr) + + (nr_cpus + 1) * sizeof(Elf64_Phdr) + (nr_ranges + 1) * sizeof(Elf64_Phdr); size = (size + EFI_PAGE_SIZE - 1) & ~(EFI_PAGE_SIZE - 1); tmp = xmalloc(size); Thanks, Akiyama, Nobuyuki On Fri, 01 Dec 2006 15:55:27 -0800 Jay Lan <jlan@xxxxxxx> wrote: > The kexec seg faulted when i ran test at an 56p SN machine. > It was successful on a 2p SN. > > > (gdb) bt > #0 0x200000000016a900 in _int_realloc () from /lib/libc.so.6.1 > #1 0x200000000016e020 in realloc () from /lib/libc.so.6.1 > #2 0x40000000000020c0 in xrealloc (ptr=0x600000000002ada0, size=160) > at kexec/kexec.c:70 > #3 0x40000000000042a0 in add_segment (info=0x60000ffffe2c3718, > buf=0x600000000002ae30, bufsz=12288, base=206963621888, memsz=16384) > at kexec/kexec.c:310 > #4 0x40000000000047f0 in add_buffer (info=0x60000ffffe2c3718, > buf=0x600000000002ae30, bufsz=12288, memsz=16384, buf_align=4096, > buf_min=0, buf_max=18446744073709551615, buf_end=-1) at > kexec/kexec.c:345 > #5 0x400000000001aa20 in load_crashdump_segments (info=0x60000ffffe2c3718, > ehdr=0x60000ffffe2c3578, max_addr=18446744073709551615, min_base=0, > cmdline=0x60000ffffe2c35e8) at kexec/arch/ia64/crashdump-ia64.c:328 > #6 0x4000000000016970 in elf_ia64_load (argc=6, argv=0x60000ffffe2c3af8, > buf=0x2000000000324010 "\177ELF\002\001\001", len=15939392, > info=0x60000ffffe2c3718) at kexec/arch/ia64/kexec-elf-ia64.c:203 > #7 0x4000000000006a00 in my_load (type=0x0, fileind=5, argc=6, > argv=0x60000ffffe2c3af8, kexec_flags=1) at kexec/kexec.c:617 > #8 0x4000000000008220 in main (argc=6, argv=0x60000ffffe2c3af8) > at kexec/kexec.c:859 > (gdb) > > The add_segment() contains code as below: > > add_segment() > { > ... > last = base + memsz -1; > if (!valid_memory_range(base, last)) { > die("Invalid memory segment %p - %p\n", > (void *)base, (void *)last); > } > > size = (info->nr_segments + 1) * sizeof(info->segment[0]); > info->segment = xrealloc(info->segment, size); <====== seg fault > info->segment[info->nr_segments].buf = buf; > info->segment[info->nr_segments].bufsz = bufsz; > info->segment[info->nr_segments].mem = (void *)base; > info->segment[info->nr_segments].memsz = memsz; > > info->nr_segments++; > ... > } > > The seg fault happened on nr_segment=4. At the end of nr_segment=3 > info->segment was set to 2ada0 in the statement > info->segment = xrealloc(info->segment, size); > And the subsequent call to xrealloc() on nr_segment=4, it died. > > On the 2p machine that was successful, the info->segment was set to > 29310 at the end of nr_segment=3. It went all the way to 30b10 at > the end of 9th segment. So, the value 2ada0 seems still in the bound. > > Can anyone more familiar with xrealloc and kexec tell me what might > cause the seg fault? > > Thanks, > - jay > _______________________________________________ > fastboot mailing list > fastboot@xxxxxxxxxxxxxx > https://lists.osdl.org/mailman/listinfo/fastboot > - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |