2 Jul 2007 15:15
2 Jul 2007 18:04
Re: problem with elfutils-0.125 for makedumpfile
Hi Ken'ichi Ohmichi, Sorry for delayed reply!! I was not at work. No, I tried with what you say but I am getting many error!! I think this is the problem with the PATH (?). [makedumpfile]# make gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -DVERSION='"1.1.4"' -DRELEASE_DATE='"08 June 2007"' -D__x86_64__ x86.o x86_64.o ia64.o ppc64.o -o makedumpfile makedumpfile.c -static -ldw -lelf -lz makedumpfile.c: In function `write_kdump_pages': makedumpfile.c:4102: warning: implicit declaration of function `compressBound' /tmp/ccwAfYOX.o(.text+0xa082): In function `write_kdump_pages': /root/makedumpfile/makedumpfile.c:4102: undefined reference to `compressBound' collect2: ld returned 1 exit status make: *** [makedumpfile] Error 1 [root <at> ssn258 makedumpfile]# gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -DVERSION='"1.1.4"' -DRELEASE_DATE='"08 June 2007"' -D__x86_64__ x86.o x86_64.o ia64.o ppc64.o -o makedumpfile makedumpfile.c -static -lelf -lz makedumpfile.c: In function `write_kdump_pages': makedumpfile.c:4102: warning: implicit declaration of function `compressBound' /tmp/ccFds0fs.o(.text+0x29f7): In function `get_data_member_location': /root/makedumpfile/makedumpfile.c:967: undefined reference to `dwarf_attr' /tmp/ccFds0fs.o(.text+0x2a1a):/root/makedumpfile/makedumpfile.c:970: undefined reference to `dwarf_getlocation' /tmp/ccFds0fs.o(.text+0x2a6f): In function `get_die_type': /root/makedumpfile/makedumpfile.c:984: undefined reference to `dwarf_dieoffset' /tmp/ccFds0fs.o(.text+0x2a7a):/root/makedumpfile/makedumpfile.c:984: undefined reference to `dwarf_cuoffset' /tmp/ccFds0fs.o(.text+0x2a8d):/root/makedumpfile/makedumpfile.c:989: undefined reference to `dwarf_attr' /tmp/ccFds0fs.o(.text+0x2ac1):/root/makedumpfile/makedumpfile.c:992: undefined reference to `dwarf_formref'(Continue reading)
3 Jul 2007 07:12
Re: ELF64 header on i386
On Mon, Jul 02, 2007 at 03:15:41PM +0200, Bernhard Walle wrote: > Hello, > > why creates kexec-tools ELF64 headers per default on i386? Wouldn't it > make more sense to look if a physical address exceeds the 32-bit limit > and then switch to ELF64 automatically if the user doesn't have > specified an option? > I am aware of one issue, that gdb on i386 is not able to analyse ELF64 formatted kdump though "crash" can. Thanks Maneesh -- -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India
3 Jul 2007 11:00
Re: problem with elfutils-0.125 for makedumpfile
Hi Dharmosoth, Thank you for the information. 2007/07/02 08:04:08 -0800, Dharmosoth Seetharam <dseetharam@...> wrote: >No, I tried with what you say but I am getting many error!! > >I think this is the problem with the PATH (?). > > >[makedumpfile]# make >gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -DVERSION='"1.1.4"' -DRELEASE_DATE='"08 June 2007"' -D__x86_64__ x86.o x86_64.o ia64.o ppc64.o -o makedumpfile makedumpfile.c -static -ldw -lelf -lz >makedumpfile.c: In function `write_kdump_pages': >makedumpfile.c:4102: warning: implicit declaration of function `compressBound' >/tmp/ccwAfYOX.o(.text+0xa082): In function `write_kdump_pages': >/root/makedumpfile/makedumpfile.c:4102: undefined reference to `compressBound' >collect2: ld returned 1 exit status >make: *** [makedumpfile] Error 1 >[root <at> ssn258 makedumpfile]# gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -DVERSION='"1.1.4"' -DRELEASE_DATE='"08 June 2007"' -D__x86_64__ x86.o x86_64.o ia64.o ppc64.o -o makedumpfile makedumpfile.c -static -lelf -lz >makedumpfile.c: In function `write_kdump_pages': >makedumpfile.c:4102: warning: implicit declaration of function `compressBound' >/tmp/ccFds0fs.o(.text+0x29f7): In function `get_data_member_location': >/root/makedumpfile/makedumpfile.c:967: undefined reference to `dwarf_attr' >/tmp/ccFds0fs.o(.text+0x2a1a):/root/makedumpfile/makedumpfile.c:970: undefined reference to `dwarf_getlocation'(Continue reading)
3 Jul 2007 18:12
[PATCH] Determine ELF32/ELF64 automatically on i386
On i386, kexec generates ELF64 core headers by default if the user doesn't override this via a command line option. Because GDB cannot analyse ELF64 core dumps on 32 bit platforms, it's a bad idea to use ELF64 if it's not needed. This patch selects ELF32 if the biggest memory address fits in 32 bit address space, which should be the case on non PAE systems. If the user specifies a command line option, that option overrides the detection. Signed-off-by: Bernhard Walle <bwalle@...> --- kexec/arch/i386/crashdump-x86.c | 26 ++++++++++++++++++++++++++ kexec/arch/i386/kexec-x86.c | 2 +- kexec/arch/i386/kexec-x86.h | 20 ++++++++++++-------- 3 files changed, 39 insertions(+), 9 deletions(-) --- a/kexec/arch/i386/crashdump-x86.c +++ b/kexec/arch/i386/crashdump-x86.c <at> <at> -486,6 +486,23 <at> <at> static struct crash_elf_info elf_info32 get_note_info: get_crash_notes, }; +static enum CoreType get_core_type(struct kexec_info *info, + struct memory_range *range, int ranges) +{ + if (info->kexec_flags & KEXEC_ARCH_X86_64) + return CORE_TYPE_ELF64; + else { + /* fall back to default */(Continue reading)
3 Jul 2007 22:24
Re: kexec fails (pretty often)
"Natalie Protasevich" <protasnb@...> writes: > I came across a report about panics on a IA64 system that happen when > kexec is being executed. The FSB parity error gets generated: > > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > Processor Request > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > the Deferred Reply > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > the Deferred Reply > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > the Deferred Reply > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > the Deferred Reply > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > Processor Request > > > And the pattern of the address on the bus is actually coming from the > piece of code in arch/ia64/kernel/gate.S, calculating ar.bpstore: > > ... > sub r14=r14,r17 // r14 <- -rse_num_regs(bspstore1, bsp1) > movl r17=0x8208208208208209 > ;; > add r18=r18,r14 // r18 (delta) <- rse_slot_num(bsp0) - > rse_num_regs(bspstore1,bsp1) > setf.sig f7=r17 > cmp.lt p7,p0=r14,r0 // p7 <- (r14 < 0)?(Continue reading)
4 Jul 2007 02:29
Re: kexec fails (pretty often)
On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote: > "Natalie Protasevich" <protasnb@...> writes: > > > I came across a report about panics on a IA64 system that happen when > > kexec is being executed. The FSB parity error gets generated: > > > > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > > Processor Request > > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > > the Deferred Reply > > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > > the Deferred Reply > > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > > the Deferred Reply > > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > > the Deferred Reply > > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > > Processor Request > > > > > > And the pattern of the address on the bus is actually coming from the > > piece of code in arch/ia64/kernel/gate.S, calculating ar.bpstore: > > > > ... > > sub r14=r14,r17 // r14 <- -rse_num_regs(bspstore1, bsp1) > > movl r17=0x8208208208208209 > > ;; > > add r18=r18,r14 // r18 (delta) <- rse_slot_num(bsp0) - > > rse_num_regs(bspstore1,bsp1) > > setf.sig f7=r17(Continue reading)
4 Jul 2007 06:22
Re: kexec fails (pretty often)
On 04 Jul 2007 08:29:39 +0800, Zou Nan hai <nanhai.zou@...> wrote: > On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote: > > "Natalie Protasevich" <protasnb@...> writes: > > > > > I came across a report about panics on a IA64 system that happen when > > > kexec is being executed. The FSB parity error gets generated: > > > > > > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > > > Processor Request > > > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > > > the Deferred Reply > > > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > > > the Deferred Reply > > > BRLD / WB to xFFFFFFF0028, A43:41 = x7, FSB Parity Error detected on > > > the Deferred Reply > > > BRLC / UC to xFFFF2000000, A43:41 = x7, FSB Parity Error detected on > > > the Deferred Reply > > > BRLD / UC to x8208208208, A43:41 = x0, FSB Parity Error detected on > > > Processor Request > > > > > > > > > And the pattern of the address on the bus is actually coming from the > > > piece of code in arch/ia64/kernel/gate.S, calculating ar.bpstore: > > > > > > ... > > > sub r14=r14,r17 // r14 <- -rse_num_regs(bspstore1, bsp1) > > > movl r17=0x8208208208208209 > > > ;; > > > add r18=r18,r14 // r18 (delta) <- rse_slot_num(bsp0) - > > > rse_num_regs(bspstore1,bsp1)(Continue reading)
4 Jul 2007 11:40
[ANNOUNCE] The Linux Test Project has been Released for June 2007,
Subrata Modak <subrata <at> linux.vnet.ibm.com>
2007-07-04 09:40:35 GMT
2007-07-04 09:40:35 GMT
Dear All, The Linux Test Project test suite <http://www.linuxtestproject.org> has been released for the month of June 2007. The latest version of the testsuite contains 3000+ tests for the Linux OS and can be found at http://prdownloads.sourceforge.net/ltp/ltp-full-20070630.tgz?download. Our web site also contains other information such as: - A Linux test tools matrix - Technical papers - How To's on Linux testing - Code coverage analysis tool. Release Highlights: * Updation of OPEN_HPI_TESTSUITE from version 0.5.0 to 2.9.2 * Addition of 'writev06' testcase by <dmonakhov <at> openvz.org> to check for "fault in pages readable" functionality * Addition of 'SYSVIPC (containers)' testcases by <risrajak <at> linux.vnet.ibm.com> * KDUMP and UTSNAMESPACE testcases(s) getting more matured with more community contribution * Updation of 'fsx-linux' testcase to include new feature(s) including "Distributed filesystem coherency" by 'Andreas Dilger' * Patches to support arm eabi-compliant gcc for g-cov kernel * Many more patches to fix Bugs/anomalies in various test cases Note(s) from the Maintainer: * We have seen that the LTP mailing lists has become active for the last couple of months. Thanks to all who has made this happen. We as an integrated team can work hard to make this Project a resounding success. Following are the different milestones/activities that we aim to(Continue reading)
5 Jul 2007 16:12
[ANNOUNCE] LTP Roadmap Released
Subrata Modak <subrata <at> linux.vnet.ibm.com>
2007-07-05 14:12:37 GMT
2007-07-05 14:12:37 GMT
Hi All, Sometime back we started retrospection on LTP and the various ways to make it better. It resulted in critical evaluation of LTP within & outside LTP users community. It also reflected the various ways on making it more better and effective. Working in this direction, we have come up with a road map which we feel will be helpful to the community. The following wiki pages will throw some light on the same: * http://ltp.sourceforge.net/wiki/ * http://ltp.sourceforge.net/wikiArchives.php Your comments on the contents and the goals set will be highly appreciated. All comments will be published on the above wiki pages. Regards & Thanks-- Subrata Modak - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RSS Feed