From bwalle at suse.de  Mon Jul  2 09:15:41 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Mon, 2 Jul 2007 15:15:41 +0200
Subject: ELF64 header on i386
Message-ID: <20070702131541.GA6084@suse.de>

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?


Thanks,
   Bernhard


From dseetharam at inbox.com  Mon Jul  2 12:04:08 2007
From: dseetharam at inbox.com (Dharmosoth Seetharam)
Date: Mon, 2 Jul 2007 08:04:08 -0800
Subject: problem with elfutils-0.125 for makedumpfile
In-Reply-To: <20070615164557oomichi@mail.jp.nec.com>
References: <c6430f72a46.000002f9dseetharam@inbox.com>
Message-ID: <A96B39B9BF4.000001A6dseetharam@inbox.com>

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'
/tmp/ccFds0fs.o(.text+0x2ada):/root/makedumpfile/makedumpfile.c:995: undefined reference to `dwarf_offdie'
/tmp/ccFds0fs.o(.text+0x2bd7): In function `get_data_array_length':
/root/makedumpfile/makedumpfile.c:1014: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2beb):/root/makedumpfile/makedumpfile.c:1025: undefined reference to `dwarf_child'
/tmp/ccFds0fs.o(.text+0x2bf4):/root/makedumpfile/makedumpfile.c:1027: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2c04):/root/makedumpfile/makedumpfile.c:1030: undefined reference to `dwarf_siblingof'
/tmp/ccFds0fs.o(.text+0x2c21):/root/makedumpfile/makedumpfile.c:1035: undefined reference to `dwarf_attr'
/tmp/ccFds0fs.o(.text+0x2c35):/root/makedumpfile/makedumpfile.c:1038: undefined reference to `dwarf_formudata'
/tmp/ccFds0fs.o(.text+0x2cd6): In function `check_array_type':
/root/makedumpfile/makedumpfile.c:1059: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2d15): In function `search_member':
/root/makedumpfile/makedumpfile.c:1073: undefined reference to `dwarf_child'
/tmp/ccFds0fs.o(.text+0x2d2a):/root/makedumpfile/makedumpfile.c:1079: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2d34):/root/makedumpfile/makedumpfile.c:1080: undefined reference to `dwarf_diename'
/tmp/ccFds0fs.o(.text+0x2d44):/root/makedumpfile/makedumpfile.c:1114: undefined reference to `dwarf_siblingof'
/tmp/ccFds0fs.o(.text+0x2e07): In function `search_structure':
/root/makedumpfile/makedumpfile.c:1164: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2e11):/root/makedumpfile/makedumpfile.c:1165: undefined reference to `dwarf_diename'
/tmp/ccFds0fs.o(.text+0x2e21):/root/makedumpfile/makedumpfile.c:1177: undefined reference to `dwarf_siblingof'
/tmp/ccFds0fs.o(.text+0x2e8c):/root/makedumpfile/makedumpfile.c:1172: undefined reference to `dwarf_bytesize'
/tmp/ccFds0fs.o(.text+0x2ed8): In function `search_srcfile':
/root/makedumpfile/makedumpfile.c:1219: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2ee2):/root/makedumpfile/makedumpfile.c:1220: undefined reference to `dwarf_diename'
/tmp/ccFds0fs.o(.text+0x2ef2):/root/makedumpfile/makedumpfile.c:1231: undefined reference to `dwarf_siblingof'
/tmp/ccFds0fs.o(.text+0x2f3f):/root/makedumpfile/makedumpfile.c:1226: undefined reference to `dwarf_decl_file'
/tmp/ccFds0fs.o(.text+0x2f65): In function `search_symbol':
/root/makedumpfile/makedumpfile.c:1255: undefined reference to `dwarf_tag'
/tmp/ccFds0fs.o(.text+0x2f70):/root/makedumpfile/makedumpfile.c:1256: undefined reference to `dwarf_diename'
/tmp/ccFds0fs.o(.text+0x2f84):/root/makedumpfile/makedumpfile.c:1262: undefined reference to `dwarf_siblingof'
/tmp/ccFds0fs.o(.text+0x3048): In function `search_die_tree':
/root/makedumpfile/makedumpfile.c:1294: undefined reference to `dwarf_child'
/tmp/ccFds0fs.o(.text+0x3155): In function `get_debug_info':
/root/makedumpfile/makedumpfile.c:1337: undefined reference to `dwarf_begin_elf'
/tmp/ccFds0fs.o(.text+0x31ef):/root/makedumpfile/makedumpfile.c:1363: undefined reference to `dwarf_nextcu'
/tmp/ccFds0fs.o(.text+0x320b):/root/makedumpfile/makedumpfile.c:1366: undefined reference to `dwarf_offdie'
/tmp/ccFds0fs.o(.text+0x3242):/root/makedumpfile/makedumpfile.c:1378: undefined reference to `dwarf_end'
/tmp/ccFds0fs.o(.text+0xa082): In function `write_kdump_pages':
/root/makedumpfile/makedumpfile.c:4102: undefined reference to `compressBound'
collect2: ld returned 1 exit status

The following is the PATH:

/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:
/usr/X11R6/bin:/opt/filer/bin:/root/bin:/usr/local/include/:/usr/local:/usr/local/include/elfutils

I have copied those files to /usr/local/include/elfutils


Any comments ??

Thanks
Seetharam




> -----Original Message-----
> From: oomichi at mxs.nes.nec.co.jp
> Sent: Fri, 15 Jun 2007 16:45:57 +0900
> To: dseetharam at inbox.com
> Subject: Re: problem with elfutils-0.125 for makedumpfile
> 
> 
> Hi Dharmosoth,
> 
> 
> 2007/06/14 06:27:18 -0800, Dharmosoth Seetharam <dseetharam at inbox.com>
> wrote:
> >I tryinging to install makedumpfile utility program.
> >For this elfutils-0.125 should be installed on the same machine.
>> 
> >So, i have done the same thing.
>> 
> >After installing the "elfutils-0.125", I am getting the following error.
>> 
> >Can any one please tell me what should be the mistake i have done?
>> 
>> 
> >[root at tc210 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'
> >/usr/local/bin/ld: invalid option -- Y
> >Try `ld --help' or `ld --usage' for more information.
> >collect2: ld returned 64 exit status
> >make: *** [makedumpfile] Error 1
> 
> I think the cause is 'ld' installed by elfutils-0.125.
> elfutils-0.125 installs 'ld' into /usr/local/bin/ with the library files.
> For installing only necessary files, could you please try follows ?
> 
> - Uninstall elfutils-0.125
>   # cd elfutils-0.125
>   # make uninstall
>   #
> 
> - Make elfutils-0.125, and install only the library files.
>   # make clean
>   # ./configure
>   # make
>   #
>   # mkdir /usr/local/include/elfutils/
>   # cp ./libdw/libdw.h   /usr/local/include/elfutils/libdw.h
>   # cp ./libdw/dwarf.h   /usr/local/include/dwarf.h
>   # cp ./libelf/libelf.h /usr/local/include/libelf.h
>   # cp ./libelf/gelf.h   /usr/local/include/gelf.h
>   #
>   # cp ./libelf/libelf.a /usr/local/lib/libelf.a
>   # cp ./libdw/libdw.a   /usr/local/lib/libdw.a
>   # cp ./libasm/libasm.a /usr/local/lib/libasm.a
>   # cp ./libebl/libebl.a /usr/local/lib/libebl.a
>   #
> 
> If there are not any problems, I will add the above method to README
> file.
> 
> 
> Thanks
> Ken'ichi Ohmichi

____________________________________________________________
Listen & Record Music from Internet Radio - Get Free Radio & MP3 Player & Recorder
Learn more at http://www.inbox.com/radio


From maneesh at in.ibm.com  Tue Jul  3 01:12:28 2007
From: maneesh at in.ibm.com (Maneesh Soni)
Date: Tue, 3 Jul 2007 10:42:28 +0530
Subject: ELF64 header on i386
In-Reply-To: <20070702131541.GA6084@suse.de>
References: <20070702131541.GA6084@suse.de>
Message-ID: <20070703051228.GA8394@in.ibm.com>

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


From oomichi at mxs.nes.nec.co.jp  Tue Jul  3 05:00:26 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Tue, 3 Jul 2007 18:00:26 +0900
Subject: problem with elfutils-0.125 for makedumpfile
In-Reply-To: <A96B39B9BF4.000001A6dseetharam@inbox.com>
References: <A96B39B9BF4.000001A6dseetharam@inbox.com>
Message-ID: <20070703180026oomichi@mail.jp.nec.com>


Hi Dharmosoth,

Thank you for the information.


2007/07/02 08:04:08 -0800, Dharmosoth Seetharam <dseetharam at inbox.com> 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'
>/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'
>/tmp/ccFds0fs.o(.text+0x2ada):/root/makedumpfile/makedumpfile.c:995: undefined reference to `dwarf_offdie'
>/tmp/ccFds0fs.o(.text+0x2bd7): In function `get_data_array_length':
>/root/makedumpfile/makedumpfile.c:1014: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2beb):/root/makedumpfile/makedumpfile.c:1025: undefined reference to `dwarf_child'
>/tmp/ccFds0fs.o(.text+0x2bf4):/root/makedumpfile/makedumpfile.c:1027: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2c04):/root/makedumpfile/makedumpfile.c:1030: undefined reference to `dwarf_siblingof'
>/tmp/ccFds0fs.o(.text+0x2c21):/root/makedumpfile/makedumpfile.c:1035: undefined reference to `dwarf_attr'
>/tmp/ccFds0fs.o(.text+0x2c35):/root/makedumpfile/makedumpfile.c:1038: undefined reference to `dwarf_formudata'
>/tmp/ccFds0fs.o(.text+0x2cd6): In function `check_array_type':
>/root/makedumpfile/makedumpfile.c:1059: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2d15): In function `search_member':
>/root/makedumpfile/makedumpfile.c:1073: undefined reference to `dwarf_child'
>/tmp/ccFds0fs.o(.text+0x2d2a):/root/makedumpfile/makedumpfile.c:1079: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2d34):/root/makedumpfile/makedumpfile.c:1080: undefined reference to `dwarf_diename'
>/tmp/ccFds0fs.o(.text+0x2d44):/root/makedumpfile/makedumpfile.c:1114: undefined reference to `dwarf_siblingof'
>/tmp/ccFds0fs.o(.text+0x2e07): In function `search_structure':
>/root/makedumpfile/makedumpfile.c:1164: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2e11):/root/makedumpfile/makedumpfile.c:1165: undefined reference to `dwarf_diename'
>/tmp/ccFds0fs.o(.text+0x2e21):/root/makedumpfile/makedumpfile.c:1177: undefined reference to `dwarf_siblingof'
>/tmp/ccFds0fs.o(.text+0x2e8c):/root/makedumpfile/makedumpfile.c:1172: undefined reference to `dwarf_bytesize'
>/tmp/ccFds0fs.o(.text+0x2ed8): In function `search_srcfile':
>/root/makedumpfile/makedumpfile.c:1219: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2ee2):/root/makedumpfile/makedumpfile.c:1220: undefined reference to `dwarf_diename'
>/tmp/ccFds0fs.o(.text+0x2ef2):/root/makedumpfile/makedumpfile.c:1231: undefined reference to `dwarf_siblingof'
>/tmp/ccFds0fs.o(.text+0x2f3f):/root/makedumpfile/makedumpfile.c:1226: undefined reference to `dwarf_decl_file'
>/tmp/ccFds0fs.o(.text+0x2f65): In function `search_symbol':
>/root/makedumpfile/makedumpfile.c:1255: undefined reference to `dwarf_tag'
>/tmp/ccFds0fs.o(.text+0x2f70):/root/makedumpfile/makedumpfile.c:1256: undefined reference to `dwarf_diename'
>/tmp/ccFds0fs.o(.text+0x2f84):/root/makedumpfile/makedumpfile.c:1262: undefined reference to `dwarf_siblingof'
>/tmp/ccFds0fs.o(.text+0x3048): In function `search_die_tree':
>/root/makedumpfile/makedumpfile.c:1294: undefined reference to `dwarf_child'
>/tmp/ccFds0fs.o(.text+0x3155): In function `get_debug_info':
>/root/makedumpfile/makedumpfile.c:1337: undefined reference to `dwarf_begin_elf'
>/tmp/ccFds0fs.o(.text+0x31ef):/root/makedumpfile/makedumpfile.c:1363: undefined reference to `dwarf_nextcu'
>/tmp/ccFds0fs.o(.text+0x320b):/root/makedumpfile/makedumpfile.c:1366: undefined reference to `dwarf_offdie'
>/tmp/ccFds0fs.o(.text+0x3242):/root/makedumpfile/makedumpfile.c:1378: undefined reference to `dwarf_end'
>/tmp/ccFds0fs.o(.text+0xa082): In function `write_kdump_pages':
>/root/makedumpfile/makedumpfile.c:4102: undefined reference to `compressBound'
>collect2: ld returned 1 exit status
>
>The following is the PATH:
>
>/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:
>/usr/X11R6/bin:/opt/filer/bin:/root/bin:/usr/local/include/:/usr/local:/usr/local/include/elfutils
>
>I have copied those files to /usr/local/include/elfutils

Did you copy all files (libdw.h, dwarf.h, libelf.h, gelf.h, libelf.a, libdw.a,
libasm.a, and libebl.a) to the paths I specified ?

>>   # cp ./libdw/libdw.h   /usr/local/include/elfutils/libdw.h
>>   # cp ./libdw/dwarf.h   /usr/local/include/dwarf.h
>>   # cp ./libelf/libelf.h /usr/local/include/libelf.h
>>   # cp ./libelf/gelf.h   /usr/local/include/gelf.h
>>   #
>>   # cp ./libelf/libelf.a /usr/local/lib/libelf.a
>>   # cp ./libdw/libdw.a   /usr/local/lib/libdw.a
>>   # cp ./libasm/libasm.a /usr/local/lib/libasm.a
>>   # cp ./libebl/libebl.a /usr/local/lib/libebl.a


If you do it and get the above error, could you please change makedumpfile's
Makefile like the following (-L/usr/local/lib/ is added) ?
And let me know the result.

CFLAGS = -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -L/usr/local/lib/ \
          -DVERSION='"$(VERSION)"' -DRELEASE_DATE='"$(DATE)"'

And I guess your system doesn't have zlib library.
Could you check it also ?


Thanks
Ken'ichi Ohmichi


From bwalle at suse.de  Tue Jul  3 12:12:07 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 3 Jul 2007 18:12:07 +0200
Subject: [PATCH] Determine ELF32/ELF64 automatically on i386
In-Reply-To: <20070702131541.GA6084@suse.de>
References: <20070702131541.GA6084@suse.de>
Message-ID: <20070703161207.GA5070@suse.de>

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 at suse.de>

---
 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
@@ -486,6 +486,23 @@ 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 */
+		if (ranges == 0)
+			return CORE_TYPE_ELF64;
+
+		if (range[ranges].end > 0xFFFFFFFFUL)
+			return CORE_TYPE_ELF64;
+		else
+			return CORE_TYPE_ELF32;
+	}
+}
+
 /* Loads additional segments in case of a panic kernel is being loaded.
  * One segment for backup region, another segment for storing elf headers
  * for crash memory image.
@@ -501,6 +518,15 @@ int load_crashdump_segments(struct kexec
 	if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
 		return -1;
 
+	/*
+	 * if the core type has not been set on command line, set it here
+	 * automatically
+	 */
+	if (arch_options.core_header_type == CORE_TYPE_UNDEF) {
+		arch_options.core_header_type =
+			get_core_type(info, mem_range, nr_ranges);
+	}
+
 	/* Memory regions which panic kernel can safely use to boot into */
 	sz = (sizeof(struct memory_range) * (KEXEC_MAX_SEGMENTS + 1));
 	memmap_p = xmalloc(sz);
--- a/kexec/arch/i386/kexec-x86.c
+++ b/kexec/arch/i386/kexec-x86.c
@@ -145,7 +145,7 @@ struct arch_options_t arch_options = {
 	.serial_baud = 0,
 	.console_vga = 0,
 	.console_serial = 0,
-	.core_header_type = CORE_TYPE_ELF64,
+	.core_header_type = CORE_TYPE_UNDEF,
 };
 
 int arch_process_options(int argc, char **argv)
--- a/kexec/arch/i386/kexec-x86.h
+++ b/kexec/arch/i386/kexec-x86.h
@@ -2,8 +2,12 @@
 #define KEXEC_X86_H
 
 #define MAX_MEMORY_RANGES 64
-#define CORE_TYPE_ELF32 1
-#define CORE_TYPE_ELF64 2
+
+enum CoreType {
+	CORE_TYPE_UNDEF = 0,
+	CORE_TYPE_ELF32 = 1,
+	CORE_TYPE_ELF64 = 2
+};
 
 extern unsigned char compat_x86_64[];
 extern uint32_t compat_x86_64_size, compat_x86_64_entry32;
@@ -40,12 +44,12 @@ struct entry16_regs {
 };
 
 struct arch_options_t {
-	uint8_t  reset_vga;
-	uint16_t serial_base;
-	uint32_t serial_baud;
-	uint8_t  console_vga;
-	uint8_t  console_serial;
-	int	 core_header_type;
+	uint8_t  	reset_vga;
+	uint16_t 	serial_base;
+	uint32_t 	serial_baud;
+	uint8_t  	console_vga;
+	uint8_t  	console_serial;
+	enum CoreType	core_header_type;
 };
 
 int multiboot_x86_probe(const char *buf, off_t len);


From ebiederm at xmission.com  Tue Jul  3 16:24:50 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 03 Jul 2007 14:24:50 -0600
Subject: kexec fails (pretty often)
In-Reply-To: <32209efe0707030906r58993b12se9a4b9dab409a15@mail.gmail.com>
	(Natalie Protasevich's message of "Tue, 3 Jul 2007 10:06:40 -0600")
References: <32209efe0707030906r58993b12se9a4b9dab409a15@mail.gmail.com>
Message-ID: <m1d4z9i6b1.fsf@ebiederm.dsl.xmission.com>

"Natalie Protasevich" <protasnb at gmail.com> 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)?
>        ;;
> ...
>
> Have you seen such error before? What would you recommend for debugging this?

Not really.

However this sounds fairly deterministic on the hardware involved.
So I would recommend a code audit.

With low-level kexec code like this it really requires someone who knows
the architecture to think through the code.

Adding in serial output into the assembly and what not can help to
isolate the piece of the code causing the problem.  But it looks
like you have done that.

You haven't provided quite enough context for me to understand how
this code sequence is reproduced.  I would certainly need more
information then you have given to even locate the code path this is
coming from, as it has been a long time since I looked at ia64.

I have CC'd a few likely suspects and the kexec list so with a little
luck if anyone is familiar with this they can answer you.

Eric


From nanhai.zou at intel.com  Tue Jul  3 20:29:39 2007
From: nanhai.zou at intel.com (Zou Nan hai)
Date: 04 Jul 2007 08:29:39 +0800
Subject: kexec fails (pretty often)
In-Reply-To: <m1d4z9i6b1.fsf@ebiederm.dsl.xmission.com>
References: <32209efe0707030906r58993b12se9a4b9dab409a15@mail.gmail.com>
	<m1d4z9i6b1.fsf@ebiederm.dsl.xmission.com>
Message-ID: <1183508979.22024.8.camel@linux-znh>

On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote:
> "Natalie Protasevich" <protasnb at gmail.com> 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)?
> >        ;;
> > ...
> >


Hi,

Is the problem reproducible? Is there any special configuration or kexec
command line option to reproduce it? 
On which platform and which version of kernel did you see the issue?

It looks like there may be something wrong with the memory map setting
of the second kernel.
Can you send me copies of /proc/iomem of the first kernel and the second
kernel?

Thanks
Zou Nan hai


> > Have you seen such error before? What would you recommend for debugging this?
> 
> Not really.
> 
> However this sounds fairly deterministic on the hardware involved.
> So I would recommend a code audit.
> 
> With low-level kexec code like this it really requires someone who knows
> the architecture to think through the code.
> 
> Adding in serial output into the assembly and what not can help to
> isolate the piece of the code causing the problem.  But it looks
> like you have done that.
> 
> You haven't provided quite enough context for me to understand how
> this code sequence is reproduced.  I would certainly need more
> information then you have given to even locate the code path this is
> coming from, as it has been a long time since I looked at ia64.
> 
> I have CC'd a few likely suspects and the kexec list so with a little
> luck if anyone is familiar with this they can answer you.
> 
> Eric


From protasnb at gmail.com  Wed Jul  4 00:22:06 2007
From: protasnb at gmail.com (Natalie Protasevich)
Date: Tue, 3 Jul 2007 21:22:06 -0700
Subject: kexec fails (pretty often)
In-Reply-To: <1183508979.22024.8.camel@linux-znh>
References: <32209efe0707030906r58993b12se9a4b9dab409a15@mail.gmail.com>
	<m1d4z9i6b1.fsf@ebiederm.dsl.xmission.com>
	<1183508979.22024.8.camel@linux-znh>
Message-ID: <32209efe0707032122l4b640f4alade21d8873ab3f9e@mail.gmail.com>

On 04 Jul 2007 08:29:39 +0800, Zou Nan hai <nanhai.zou at intel.com> wrote:
> On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote:
> > "Natalie Protasevich" <protasnb at gmail.com> 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)?
> > >        ;;
> > > ...
> > >
>
>
> Hi,
>
> Is the problem reproducible? Is there any special configuration or kexec
> command line option to reproduce it?
> On which platform and which version of kernel did you see the issue?
>
> It looks like there may be something wrong with the memory map setting
> of the second kernel.
> Can you send me copies of /proc/iomem of the first kernel and the second
> kernel?
>

Thanks! I will try to get as much information as I can.
It is 100 % reproducible, but intermittent - another words happens
with each run, but not predictably (I will get more precise scenario).
This is a large ES7000 server with up to 512 processors, I will find
out if this happens with large configuration or any.
Kernel is the SLES10 or RHEL4U5, they use both.
I will provide the iomem, not sure how soon - either tomorrow or after
the holiday...

Regards,
--Natalie
> Thanks
> Zou Nan hai
>
>
> > > Have you seen such error before? What would you recommend for debugging this?
> >
> > Not really.
> >
> > However this sounds fairly deterministic on the hardware involved.
> > So I would recommend a code audit.
> >
> > With low-level kexec code like this it really requires someone who knows
> > the architecture to think through the code.
> >
> > Adding in serial output into the assembly and what not can help to
> > isolate the piece of the code causing the problem.  But it looks
> > like you have done that.
> >
> > You haven't provided quite enough context for me to understand how
> > this code sequence is reproduced.  I would certainly need more
> > information then you have given to even locate the code path this is
> > coming from, as it has been a long time since I looked at ia64.
> >
> > I have CC'd a few likely suspects and the kexec list so with a little
> > luck if anyone is familiar with this they can answer you.
> >
> > Eric
>


From subrata at linux.vnet.ibm.com  Wed Jul  4 05:40:35 2007
From: subrata at linux.vnet.ibm.com (Subrata Modak)
Date: Wed, 04 Jul 2007 15:10:35 +0530
Subject: [ANNOUNCE] The Linux Test Project has been Released for June 2007,
Message-ID: <468B6B13.8070007@linux.vnet.ibm.com>

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 
perform/achieve in the coming months:
1) Investigation into LTP Log(s) Library to make this more meaningful 
and parsible. Kindly provide your inputs for the output that LTP 
generates now and whether/how you would like it to be in future
2) Investigate all the existing test cases and find out whether they are 
relevant to today's testing of higher Kernel versions. If not, then how 
do we mold it to test the present day 
scenarios/functionalities/regressions ??
And when you investigate them you can look into the following points as 
well:
* Investigate & understand what the testcase is supposed to do, and 
increase documentation content/comments on the same testcase,
* Make the test case completely full proof to error/exception handling,
* See whether more Log library calls(existing) need to be made to 
communicate more info to the Log Library for reporting errors/exceptions 
etc,
* Is there any need to change the code to improve the stress testing the 
testcase is doing ?? or do we need to add a new testcase for doing a 
separate stress, but, for the same functionality ??
3) LTP today does not cover more than 60% of the Kernel Code coverage. 
We need to write more test cases for all those functionalities which are 
not tested by LTP today. I promise your new test case will see the light 
of next release without fail,
4) LTP wiki will be active in coming days, where we will post all those 
activities going on inside LTP,
More community contribution from all of you will decide whether all of 
these above milestones are truly and successfully completed. Kindly Pour 
in your suggestions on all those that you want to see in LTP.

New Testcases to be Added to  next  releases:
Following are the new testcases that we intend(tentative) to add in the 
next release(s) of LTP:
1) Real Time Linux Testcases
2) CPU Sets Testcases

We encourage the community to post results to ltp-results at lists.sf.net, 
and patches, new tests, bugs or comments/questions to ltp-list at lists.sf.net,
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=103382 (for 
New Bug(s)),
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=303382 (for 
New Patch(s)),
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=353382 (for 
New Feature Request(s))
 
Please also see the ChangeLog Below (June 2007):
1)Log Message: "carmelo.amoroso at st.com" points out the wrong usage of 
the option -s
File(s) Affected: ltp/testcases/kernel/mem/mtest06/mmap1.c
2)Log Message: "carmelo.amoroso at st.com" pointed out that id (returned by 
shmget) has to be used for all shm operations
File(s) Affected: ltp/testcases/kernel/mem/mtest06/shmat1.c
3)Log Message: "rsalveti at linux.vnet.ibm.com" fixed the way "inotify" 
should compile in kernels below 2.6.13
File(s) Affected: ltp/testcases/kernel/syscalls/inotify/inotify01.c
ltp/testcases/kernel/syscalls/inotify/inotify02.c
4)Log Message: Removing 'alarm04' testcase call, as alarm04 has been 
removed to be no-more-valid
File(s) Affected: ltp/runtest/ltplite
ltp/runtest/stress.part3
5)Log Message: "sachinp at in.ibm.com" rectified kdump lkdtm tests for 
powerpc architecture with RedHat distribution
File(s) Affected: ltp/testcases/kdump/rhtools/lkdtm_mod/lkdtm.c
6)Log Message: "rahaman.riaz at gmail.com" fixed some Thread Handling Anomaly
File(s) Affected: 
ltp/testcases/open_posix_testsuite/conformance/interfaces/mq_timedsend/12-1.c
7)Log Message: "rahaman.riaz at gmail.com" fixed ways by which OPEN POSIX 
displays warnings
File(s) Affected: 
open_posix_testsuite/conformance/interfaces/sem_unlink/2-2.c
open_posix_testsuite/conformance/interfaces/sigaltstack/9-1.c
8)Log Message: "yxu at suse.de" corrected the way by which pthread_exit() 
handles pointer argument
File(s) Affected: ltp/testcases/kernel/io/disktest/threading.h
9)Log Message: "rsalveti at linux.vnet.ibm.com" fixed the problem reported 
at bug [1732287] mtest06/mmap1.c missing run_once check in do loop
File(s) Affected: ltp/runtest/ltplite
ltp/runtest/mm
ltp/runtest/stress.part1
ltp/testcases/kernel/mem/mtest06/mmap1.c
10)Log Message: gcov-kernel: add patches to support arm eabi-compliant gcc
File(s) Affected: 
/ltp/utils/analysis/gcov-kernel/linux-2.6.18-gcov-arm-eabi.patch
/ltp/utils/analysis/gcov-kernel/linux-2.6.19-gcov-arm-eabi.patch
/ltp/utils/analysis/gcov-kernel/linux-2.6.20-gcov-arm-eabi.patch
/ltp/utils/analysis/gcov-kernel/linux-2.6.21-gcov-arm-eabi.diff
11)Log Message: "dmonakhov at openvz.org" added this test case to check for 
"fault in pages readable" functionality
File(s) Affected: ltp/runtest/stress.part3
ltp/runtest/syscalls
ltp/runtest/ltplite
File(s) Added:    ltp/testcases/kernel/syscalls/writev/writev06.c
12)Log Message: "risrajak at linux.vnet.ibm.com" added sysvipc 
(conatainers) namespace testcases
File(s) Added:    ltp/testcases/kernel/containers/sysvipc/Makefile
ltp/testcases/kernel/containers/sysvipc/runipcnstest.sh
ltp/testcases/kernel/containers/sysvipc/runtests_noltp.sh
ltp/testcases/kernel/containers/sysvipc/shmnstest.c
File(s) Affected: ltp/README ltp/testcases/kernel/containers/Makefile
ltp/testcases/kernel/containers/README
ltp/testcases/kernel/containers/container_test.sh
13)Log Message: Randy Dunlap writes: Convert kernel/sched/pthreads/*.c 
to use the standard message output functions instead of printf().
File(s) Affected: ltp/testcases/kernel/sched/pthreads/pth_str01.c
ltp/testcases/kernel/sched/pthreads/pth_str02.c
ltp/testcases/kernel/sched/pthreads/pth_str03.c
14)Log Message: "rdunlap at xenotime.net" did "mmstress" cleanups to make 
output unbuffered so that it is not produced repetitively and erroneously
File(s) Affected: ltp/testcases/kernel/mem/mtest05/mmstress.c
15)Log Message: "krisw at us.ibm.com" wants to solve segfault problem with 
"mount03" on SLES10
File(s) Affected: ltp/testcases/kernel/syscalls/mount/Makefile
ltp/testcases/kernel/syscalls/mount/mount03.c
16)Log Message: as Ricardo Salveti de Araujo points out, dont set CC so 
it can easily be overridden
File(s) Affected: ltp/testcases/kernel/containers/utsname/Makefile
17)Log Message: "Andreas Dilger" updated "fsx-linux" testcase to include 
new feature(s) including distributed filesystem coherency
Log Message:    Copyright Statements once added cannot be deleted, 
however, many Copyright Statements can co-exist
File(s) Affected: ltp/testcases/kernel/fs/fsx-linux/fsx-linux.c
18)Log Message: Fix from "rdunlap at xenotime.net" to use standard test 
results output
File(s) Affected: ltp/testcases/kernel/mem/mem/mem01.c
ltp/testcases/kernel/mem/mtest01/Makefile
ltp/testcases/kernel/mem/mtest01/mtest01.c
ltp/testcases/misc/math/float/main.c
19)Log Mesage:  "serue at us.ibm.com" fixes conatiner testing with 
'unshare' support for lower kernel versions
File(s) Affected: ltp/testcases/kernel/containers/Makefile
ltp/testcases/kernel/containers/container_test.sh
20)Log Message: Fix for Bug no "1736357",tar file is not multiplatform, 
pointed out by "Neil Brewitt"
File(s) Added:    ltp/testcases/network/nfsv4/locks/deploy_info
File(s) Deleted:  ltp/testcases/network/nfsv4/locks/DEPLOY
21)Log Message: "serue at us.ibm.com" fixes conatiner testing with 
'unshare' support for lower kernel versions
File(s) Added:    ltp/testcases/kernel/containers/check_for_unshare.c
22)Log Message: Update to OpenHPI 2.9.2
File(s) Addedd/Modified/Deleted: ltp/testcases/open_hpi_testsuite/
 
Happy testing,
Regards & Thanks--
Subrata Modak,


From subrata at linux.vnet.ibm.com  Thu Jul  5 10:12:37 2007
From: subrata at linux.vnet.ibm.com (Subrata Modak)
Date: Thu, 05 Jul 2007 19:42:37 +0530
Subject: [ANNOUNCE] LTP Roadmap Released
Message-ID: <468CFC55.4090702@linux.vnet.ibm.com>

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



From prarit at redhat.com  Thu Jul  5 11:39:35 2007
From: prarit at redhat.com (Prarit Bhargava)
Date: Thu, 05 Jul 2007 11:39:35 -0400
Subject: [IA64] [kdump] machveg=dig on hpzx1 platforms
In-Reply-To: <467AE260.7030906@hp.com>
References: <20070621182441.GA21840@suse.de> <467AE260.7030906@hp.com>
Message-ID: <468D10B7.4020600@redhat.com>


>
> Here is a patch to do that.  We use this internally, but
> I had forgotten to post it.
>

Not that it matters a huge amount, but this has been in RHEL5 for 
sometime and does fix the "machvec=dig" nuisance.

(Sorry for not replying earlier Terry -- I had a huge backlog of things 
to get to before this ...)

P.


> -T
>
> ---
> diff --git a/arch/ia64/hp/common/sba_iommu.c 
> b/arch/ia64/hp/common/sba_iommu.c
> --- a/arch/ia64/hp/common/sba_iommu.c
> +++ b/arch/ia64/hp/common/sba_iommu.c
> @@ -42,6 +42,9 @@ #include <asm/dma.h>
>  #include <asm/system.h>        /* wmb() */
>
>  #include <asm/acpi-ext.h>
> +#include <linux/crash_dump.h>
> +
> +extern int swiotlb_late_init_with_default_size (size_t size);
>
>  #define PFX "IOC: "
>
> @@ -2026,11 +2029,24 @@ sba_init(void)
>      if (!ia64_platform_is("hpzx1") && 
> !ia64_platform_is("hpzx1_swiotlb"))
>          return 0;
>
> +#ifdef CONFIG_CRASH_DUMP
> +    /* If we are booting a kdump kernel, the sba_iommu will
> +     * cause devices that were not shutdown properly to MCA
> +     * as soon as they are turned back on.  Our only option for
> +     * a successful kdump kernel boot is to use the swiotlb.
> +     */
> +    if (elfcorehdr_addr < ELFCORE_ADDR_MAX) {
> +        if (swiotlb_late_init_with_default_size(64 * (1<<20)) != 0)
> +            panic("Unable to initialize software I/O TLB:"
> +                  " Try machvec=dig boot option");
> +        machvec_init("dig");
> +        return 0;
> +    }
> +#endif
> +
>      acpi_bus_register_driver(&acpi_sba_ioc_driver);
>      if (!ioc_list) {
>  #ifdef CONFIG_IA64_GENERIC
> -        extern int swiotlb_late_init_with_default_size (size_t size);
> -
>          /*
>           * If we didn't find something sba_iommu can claim, we
>           * need to setup the swiotlb and switch to the dig machvec.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


From bwalle at suse.de  Fri Jul  6 09:28:14 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Fri, 6 Jul 2007 15:28:14 +0200
Subject: Determine version of kernel that produced vmcore
Message-ID: <20070706132814.GA7079@suse.de>

Hello,

does anybody know a _reliable_ way to determine the version the kernel
that produced a vmcore file? This means not scanning for a specific
string or something like that which can fail on random memory.

Would it make sense to add a ELF PT_NOTE section in the vmcore?

Thanks for input!



Thanks,
   Bernhard


From da-x at monatomic.org  Fri Jul  6 10:58:04 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Fri, 6 Jul 2007 17:58:04 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070706132814.GA7079@suse.de>
References: <20070706132814.GA7079@suse.de>
Message-ID: <20070706145804.GA31409@localdomain>

On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> Hello,
> 
> does anybody know a _reliable_ way to determine the version the kernel
> that produced a vmcore file? This means not scanning for a specific
> string or something like that which can fail on random memory.
> 
> Would it make sense to add a ELF PT_NOTE section in the vmcore?
> 
> Thanks for input!

(I'm sorry if this E-Mail needlessly turned into a long RFC 
but I had to bring this up when I bumped into this question on 
LKML)

Actually, instead of another ELF PT_NOTE section for this 
information and other things, kdump is currently going into 
another direction, described below.

Redhat has a makedumpinfo util which they intend to use as slim
kernel-version-independent utility on kdump rootfs in order to
save /proc/vmcore in a compact manner.

Normally makedumpinfo would require access to the vmlinux file 
that the crashed kernel was originated from. However instead of 
depending on vmlinux, it is possible to generate a small textual
"CONFIGFILE" that looks like this, for example (generated using
makedumpinfo -g):

OSRELEASE=2.6.20.3
PAGESIZE=4096
SYMBOL(mem_map)=ffffffff806cf5d8
SYMBOL(init_uts_ns)=ffffffff805f8be0
SYMBOL(_stext)=ffffffff80200f20
SYMBOL(node_online_map)=ffffffff80651bc0
SYMBOL(contig_page_data)=ffffffff80600e80
SIZE(page)=56
SIZE(pglist_data)=3712
SIZE(zone)=1152
SIZE(free_area)=24
SIZE(list_head)=16
OFFSET(page.flags)=0
OFFSET(page._count)=8
OFFSET(page.mapping)=24
OFFSET(page.lru)=40
OFFSET(pglist_data.node_zones)=0
OFFSET(pglist_data.nr_zones)=3576
OFFSET(pglist_data.node_mem_map)=3584
OFFSET(pglist_data.node_start_pfn)=3600
OFFSET(pglist_data.node_spanned_pages)=3616
OFFSET(zone.free_pages)=0
OFFSET(zone.free_area)=408
OFFSET(zone.vm_stat)=872
OFFSET(zone.spanned_pages)=1064
OFFSET(free_area.free_list)=0
OFFSET(list_head.next)=0
OFFSET(list_head.prev)=8
LENGTH(zone.free_area)=11
SRCFILE(pud_t)=include/asm/page.h

It contains enough information in order to make a compact kernel
dump (makedumpinfo needs to go over the struct page arrays). As
you see, it also contains the kernel version.

However, this file needs to be passed somehow to the rootfs
of the kdump kernel. This poses a chicken-and-egg problem on 
my setup where the initramfs of the first kernel contains 
a staticlu linked version of the kexec executable along with a
kdump kernel to be loaded before mount rootfs and running 
init. 

I used this 'crazy' kernel-packed-within-a-kernel method so 
that I wouldn't need to manage the other kernel file in the
embedded distribution I'm working on. I described this method 
to Neil Horman back in OLS last week.

A patch that I am working on will make it possible to integrate
the output of 'makedumpinfo -g' into vmlinux as the final build
stage of the kernel. This information will be presented itself
as /proc/kcore.info for the first kernel throughout its entire
execution. Then inside initramfs of the first kernel, a small 
util will modify the vmlinux file of the kdump kernel before it
gets loaded so that another special file appearing as 
/proc/vmcore.info under the kdump kernel will present the same
info. 

This way, distributions will not have to manage the packaging
of that extra file, and this is also similar to the way it was 
done with /proc/config.gz.

Originally I thought perhaps makedumpinfo can be hinted in a
way of being able to access the kallsyms info of the _crashed_
kernel and from there be able to access everything else it 
needs in a version-indepedent manner. For example, SIZE(page)
could have been presented as a simple global varible somewhere
inside the kernel:

    unsigned int kdump_size_of_pglist_data = sizeof(struct pglist_data);

If you could access the kallsyms information of the crashed
kernel from within the rootfs of the kdump kernel you can have
easily reached this variable. I think all information from
the CONFIGFILE can be 'exported' in this manner. The major
downside I can think of this approach, although it would
be quite rare - certain memory corruption bugs (especially
where kallsyms data gets squashed) can make it fail. Also,
kallsyms wastes memory on memory-limited embedded setups,
so you might not want to depend on it. Perhaps EXPORT_SYMBOL
can be used instead..

Any comments?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From protasnb at gmail.com  Sun Jul  8 13:45:27 2007
From: protasnb at gmail.com (Natalie Protasevich)
Date: Sun, 8 Jul 2007 11:45:27 -0600
Subject: kexec fails (pretty often)
In-Reply-To: <32209efe0707032122l4b640f4alade21d8873ab3f9e@mail.gmail.com>
References: <32209efe0707030906r58993b12se9a4b9dab409a15@mail.gmail.com>
	<m1d4z9i6b1.fsf@ebiederm.dsl.xmission.com>
	<1183508979.22024.8.camel@linux-znh>
	<32209efe0707032122l4b640f4alade21d8873ab3f9e@mail.gmail.com>
Message-ID: <32209efe0707081045w7f110b37h92f385d9103d49ab@mail.gmail.com>

On 7/3/07, Natalie Protasevich <protasnb at gmail.com> wrote:
> On 04 Jul 2007 08:29:39 +0800, Zou Nan hai <nanhai.zou at intel.com> wrote:
> > On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote:
> > > "Natalie Protasevich" <protasnb at gmail.com> 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)?
> > > >        ;;
> > > > ...
> > > >
> >
> >
> > Hi,
> >
> > Is the problem reproducible? Is there any special configuration or kexec
> > command line option to reproduce it?
> > On which platform and which version of kernel did you see the issue?
> >
> > It looks like there may be something wrong with the memory map setting
> > of the second kernel.
> > Can you send me copies of /proc/iomem of the first kernel and the second
> > kernel?
> >
>
> Thanks! I will try to get as much information as I can.
> It is 100 % reproducible, but intermittent - another words happens
> with each run, but not predictably (I will get more precise scenario).
> This is a large ES7000 server with up to 512 processors, I will find
> out if this happens with large configuration or any.
> Kernel is the SLES10 or RHEL4U5, they use both.
> I will provide the iomem, not sure how soon - either tomorrow or after
> the holiday...
>
Zou,

I got this information. Actually the situation is even worse than I imagined.

According to Ben who is working on this those are:

--------------------
"To sum up what happens, I do this using the default kernel command line
(and also one with "debug console=uart,io,0x3f8,115200n8 console=tty0"
added to it):

# kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5
--append=`cat /proc/cmdline`
--initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img

# kexec -e

The old kernel shuts down and boots the new one successfully, but, the
new kernel causes a fault during its boot. I can't positively identify
the exact spot it crashes because the serial output stops. Going by the
screen, it is either during or immediately after the ACPI system tries
to detect all of the CPUs. On a couple occasions I've seen it spit out
something along the lines of "EFI Time driver" before it blanks the
screen out, but it does it very quickly and the Raritan doesn't update
fast enough, even if I'm sitting at the cold floor display.

The system is configured with a single CPU, as multiple CPUs cause a
different error, something along the lines of "huh? CPU #0x200 is
already present" - but this also happened on the system without the
capacitor fix. Turning on and off hyperthreading doesn't seem to matter
either.

Here is entire log and a screen capture of the last things that
show up on the video console. The /proc/iomem contents are at line 460
in the log, and the kexec I used is at the very end. The second kernel
doesn't get far enough to enter any commands, so I'm
afraid I can't get you the /proc/iomem for that."
--------------

Please advise where he can look to analyse this.
Thanks!
--Natalie
-------------- next part --------------
Linux version 2.6.18-8.el5 (brewbuilder at hitachi-1.build.redhat.com) (gcc version
 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:16:09 EST 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
Number of logical nodes in system = 1
Number of memory chunks in system = 2
rsvd_region[0]: [0xe000000001000000, 0xe000000001000120)
rsvd_region[1]: [0xe000000004000000, 0xe000000004d54c28)
rsvd_region[2]: [0xe000001006be0010, 0xe000001006be0060)
rsvd_region[3]: [0xe000001006be3f79, 0xe000001006be4010)
rsvd_region[4]: [0xe000001006be7000, 0xe000001006f95fa9)
rsvd_region[5]: [0xe000001006f9c010, 0xe000001006f9c970)
rsvd_region[6]: [0xffffffffffffffff, 0xffffffffffffffff)
Initial ramdisk at: 0xe000001006be7000 (3862441 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4189178
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.18-8.el5 root=/dev
/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug acpi
=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.026MHz, ITC ratio=8/4, ITC freq=400.052MHz
Console: colour VGA+ 80x25
Linux version 2.6.18-8.el5 (brewbuilder at hitachi-1.build.redhat.com) (gcc version
 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:16:09 EST 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP (v002 PTLTD                                 ) @ 0x00000000000f7320
ACPI: XSDT (v001 PTLTD  	 XSDT   0x06040000  LTP 0x00000000) @ 0x00000000
fcb4aa16
ACPI: FADT (v003 UNISYS ZORRO    0x06040000 PTL  0x000f4240) @ 0x00000000fcba2cb
4
ACPI: OEM1 (v001 UNISYS   OEM1   0x06040000  LTP 0x00000000) @ 0x00000000fcba2da
8
ACPI: SRAT (v001 UNISYS   SRAT   0x06040000  LTP 0x00000000) @ 0x00000000fcba2dd
8
ACPI: IPPT (v001 UNISYS   IPPT   0x06040000  LTP 0x00000000) @ 0x00000000fcba2e6
8
ACPI: MADT (v001 PTLTD  	 APIC   0x06040000  LTP 0x00000000) @ 0x00000000
fcba2ea2
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x00000000fcba2f8
8
ACPI: SPCR (v001 PTLTD  $UCRTBL$ 0x06040000 PTL  0x00000001) @ 0x00000000fcba2fb
0
ACPI: DSDT (v001  Intel  870 SMP 0x06040000 MSFT 0x03000000) @ 0x000000000000000
0
Number of logical nodes in system = 1
Number of memory chunks in system = 2
rsvd_region[0]: [0xe000000001000000, 0xe000000001000120)
rsvd_region[1]: [0xe000000004000000, 0xe000000004d54c28)
rsvd_region[2]: [0xe000001006be0010, 0xe000001006be0060)
rsvd_region[3]: [0xe000001006be3f79, 0xe000001006be4010)
rsvd_region[4]: [0xe000001006be7000, 0xe000001006f95fa9)
rsvd_region[5]: [0xe000001006f9c010, 0xe000001006f9c970)
rsvd_region[6]: [0xffffffffffffffff, 0xffffffffffffffff)
Initial ramdisk at: 0xe000001006be7000 (3862441 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
On node 0 totalpages: 4189178
  DMA zone: 249133 pages, LIFO batch:7
  Normal zone: 3940045 pages, LIFO batch:7
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4189178
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.18-8.el5 root=/dev
/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug acpi
=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.026MHz, ITC ratio=8/4, ITC freq=400.052MHz
Console: colour VGA+ 80x25
Placing software IO TLB between 0x8eb8000 - 0xceb8000
Memory: 66595680k/67026848k available (6259k code, 448672k reserved, 4066k data,
 656k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 3194.88 BogoMIPS (lpj=1597440)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Dentry cache hash table entries: 8388608 (order: 12, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 11, 33554432 bytes)
Mount-cache hash table entries: 1024
ACPI: Core revision 20060707
Boot processor id 0x0/0x0
Brought up 1 CPUs
Total of 1 processors activated (3194.88 BogoMIPS).
sizeof(vma)=176 bytes
sizeof(page)=56 bytes
sizeof(inode)=568 bytes
sizeof(dentry)=216 bytes
sizeof(ext3inode)=776 bytes
sizeof(buffer_head)=96 bytes
sizeof(skbuff)=240 bytes
checking if image is initramfs... it is
Freeing initrd memory: 3760kB freed
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: Device [MBDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MBDV] (0000:ff)
ACPI: Device [MEDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MEDV] (0000:fe)
ACPI: PCI Root Bridge [S0H0] (0000:00)
PCI quirk: region 0d00-0d7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0d80-0dbf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 6 10 *11 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0.PCI1._PRT]
ACPI: PCI Root Bridge [S0H1] (0000:02)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI1._PRT]
ACPI: PCI Root Bridge [S0H2] (0000:09)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 9 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 8388608 (order: 13, 134217728 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 8388608 bind 65536)
TCP reno registered
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
audit: initializing netlink socket (disabled)
audit(1183730709.630:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 16384 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 47634A68C1FD4634
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x1
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x2
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x3
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x4
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x5
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x6
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x7
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x8
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x9
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xa
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xb
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xc
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xd
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xe
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xf
EFI Time Services Driver v0.4
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled
?00:06: ttyS0 at I/O 0x3f8 (irq = 44) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Device 0000:00:1f.1 not available because of resource collisions
GSI 18 (level, low) -> CPU 0 (0x0000) vector 48
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 48
ICH4: BIOS configuration fixed.
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x0880-0x0887, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x0888-0x088f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-6750A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 34
Probing IDE interface ide1...
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
ide-floppy driver 0.99.newide
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EFI Variables Facility v0.08 2004-May-17
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Adding console on ttyS0 at I/O port 0x3f8 (options '115200n8')
Freeing unused kernel memory: 656kB freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
GSI 16 (level, low) -> CPU 0 (0x0000) vector 49
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 49
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 49, io base 0x00000800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
GSI 19 (level, low) -> CPU 0 (0x0000) vector 50
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 50
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 50, io base 0x00000820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 48
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 48, io base 0x00000840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Loading ohci-hcd.ko module
usb 2-1: new full speed USB device using uhci_hcd and address 2
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
Loading ehci-hcd.ko module
GSI 23 (level, low) -> CPU 0 (0x0000) vector 51
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 51
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: slot 0000:00:1d.7 has incorrect PCI cache line size of 0 bytes, correcting 
to 128
ehci_hcd 0000:00:1d.7: irq 51, io mem 0xf7fffc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
Loading jbd.ko module
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_sas.ko module
Loading mptbase.ko module
Fusion MPT base driver 3.04.02
Copyright (c) 1999-2005 LSI Logic Corporation
usb 2-1: device not accepting address 2, error -71
Loading mptscsih.ko module
Loading mptsas.ko module
Fusion MPT SAS Host driver 3.04.02
GSI 48 (level, low) -> CPU 0 (0x0000) vector 52
ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 52
mptbase: Initiating ioc0 bringup
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
input: Unisys Corporation as /class/input/input0
input: USB HID v1.01 Keyboard [Unisys Corporation] on usb-0000:00:1d.1-1
input: Unisys Corporation as /class/input/input1
input: USB HID v1.01 Mouse [Unisys Corporation] on usb-0000:00:1d.1-1
usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input2
input: USB HID v1.00 Keyboard [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-
0000:00:1d.2-1
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input3
input: USB HID v1.00 Mouse [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-000
0:00:1d.2-1
ioc0: SAS1068: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1068, FwRev=010a0000h, Ports=1, MaxQ=511, IRQ=52
  Vendor: FUJITSU   Model: MAV2073RC         Rev: 0109
  Type:   Direct-Access                      ANSI SCSI revision: 03
SCSI device sda: 140625000 512-byte hdwr sectors (72000 MB)
sda: Write Protect is off
sda: Mode Sense: bf 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 140625000 512-byte hdwr sectors (72000 MB)
sda: Write Protect is off
sda: Mode Sense: bf 00 00 08
SCSI device sda: drive cache: write back
 sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-09-14) initialised: dm-devel at redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Waiting for driver initialization.
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1183730730.082:2): selinux=0 auid=4294967295
INIT: version 2.86 booting
		Welcome to Red Hat Enterprise Linux Server
		Press 'I' to enter interactive startup.
Setting clock  (utc): Fri Jul  6 10:05:33 EDT 2007 [  OK  ]
Starting udev: [  OK  ]
Loading default keymap (us): [  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Setting up Logical Volume Management:   /dev/hda: open failed: No medium found
  2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 155088/17039360 files, 2071435/17039360 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting background readahead: [  OK  ]
Checking for hardware changes [  OK  ]
Loading uscd driver...[  OK  ]
Starting uscm services...[  OK  ]
Starting uscr services...[  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
[  OK  ]
Bringing up interface eth1:  
Determining IP information for eth1... failed; no link present.  Check cable?
[FAILED]
Starting auditd: [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting portmap: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: [  OK  ]
Starting kdump:[FAILED]
Starting system message bus: [  OK  ]
Starting Bluetooth services:[  OK  ][  OK  ]
Mounting other filesystems:  [  OK  ]
Starting PC/SC smart card daemon (pcscd): [  OK  ]
Starting hidd: [  OK  ]
Starting autofs:  Loading autofs4: [  OK  ]
Starting automount: [  OK  ]
[  OK  ]
Starting acpi daemon: [  OK  ]
Starting hpiod: [  OK  ]
Starting hpssd: [  OK  ]
Starting cups: [  OK  ]
Starting sshd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting console mouse services: [  OK  ]
Starting crond: [  OK  ]
Starting xfs: [  OK  ]
Starting anacron: [  OK  ]
Starting atd: [  OK  ]
Starting salinfo_decode_all: [  OK  ]
Starting yum-updatesd: [  OK  ]
Starting Avahi daemon... [  OK  ]
Starting HAL daemon: [  OK  ]
Starting smartd: [  OK  ]

Red Hat Enterprise Linux Server release 5 (Tikanga)
Kernel 2.6.18-8.el5 on an ia64

localhost.localdomain login: root
Password: 
Last login: Fri Jul  6 10:06:11 on tty1
[root at localhost ~]# cat /proc/iomem 
00000000-00000fff : System RAM
00001000-00089fff : System RAM
0008a000-0009ffff : System RAM
000a0000-000fffff : PCI Bus 0000:00
  000c0000-000fffff : reserved
00100000-03ffffff : System RAM
04000000-04d54fff : System RAM
  04000000-0461ce3f : Kernel code
  0461ce40-04d54c27 : Kernel data
04d55000-37dfffff : System RAM
37e00000-37efffff : reserved
37f00000-efffffff : System RAM
f2000000-f3ffffff : PCI Bus 0000:09
  f2e00000-f2ffffff : PCI Bus #0d
    f2effc00-f2effcff : 0000:0d:1f.0
  f3e00000-f3efffff : PCI Bus #0d
  f3f00000-f3ffffff : PCI Bus #0a
    f3fc0000-f3fdffff : 0000:0a:01.1
      f3fc0000-f3fdffff : e1000
    f3fe0000-f3ffffff : 0000:0a:01.0
      f3fe0000-f3ffffff : e1000
f4000000-f4ffffff : PCI Bus 0000:02
  f4f00000-f4ffffff : PCI Bus #06
    f4fec000-f4feffff : 0000:06:01.0
    f4ff0000-f4ffffff : 0000:06:01.0
f5000000-f7ffffff : PCI Bus 0000:00
  f6000000-f7efffff : PCI Bus #01
    f6000000-f6ffffff : 0000:01:01.0
    f7ef8000-f7efbfff : 0000:01:02.0
    f7efc000-f7efcfff : 0000:01:03.0
    f7efd000-f7efdfff : 0000:01:03.0
    f7efe800-f7efefff : 0000:01:02.0
    f7eff000-f7efffff : 0000:01:01.0
  f7fffc00-f7ffffff : 0000:00:1d.7
    f7fffc00-f7ffffff : ehci_hcd
f8000000-fc72bfff : System RAM
fc72c000-fcc65fff : reserved
fcc66000-fcca5fff : reserved
fcca6000-fcffffff : reserved
fd000000-fd2fffff : reserved
fd300000-fdec8fff : System RAM
fdec9000-fdedffff : System RAM
fdee0000-fdee7fff : reserved
fdee8000-fdeedfff : System RAM
fdeee000-fdffffff : reserved
fec02000-fec02fff : 0000:02:1c.0
fec03000-fec03fff : 0000:02:1e.0
fec04000-fec04fff : 0000:09:1c.0
fec05000-fec05fff : 0000:09:1e.0
ff000000-ff01ffff : reserved
ff42a000-ff469fff : reserved
ff800000-ffffffff : reserved
100000000-1006bdffff : System RAM
1006be0000-1006be5fff : System RAM
  1006be0010-1006be0060 : Boot parameter
1006be6000-1006be6fff : System RAM
1006be7000-1006f9ffff : System RAM
  1006f9c010-1006f9c970 : EFI Memory Map
1006fa0000-1006fa0fff : System RAM
1006fa1000-1006ffdfff : System RAM
1006ffe000-1007152fff : System RAM
1007153000-1007800fff : System RAM
1007801000-1007919fff : System RAM
100791a000-100791bfff : System RAM
100791c000-100791dfff : System RAM
100791e000-1007923fff : System RAM
1007924000-1007925fff : System RAM
1007926000-10079f9fff : System RAM
10079fa000-10079fafff : System RAM
10079fb000-10079fdfff : System RAM
10079fe000-1007cfbfff : System RAM
1007cfc000-1007d65fff : reserved
1007d66000-1007dcffff : System RAM
1007dd0000-1007dfdfff : System RAM
1007dfe000-1007e29fff : System RAM
1007e2a000-1007e2bfff : reserved
1007e2c000-1007e2dfff : System RAM
1007e2e000-1007e7dfff : reserved
1007e7e000-1007fb5fff : System RAM
1007fb6000-1007ffffff : reserved
ffffc000000-ffffc7fffff : PCI Bus 0000:00 I/O Ports 00000000-00001fff
ffffc800000-ffffc9ff7ff : PCI Bus 0000:02 I/O Ports 00002000-000027ff
ffffca00800-fffffffffff : PCI Bus 0000:09 I/O Ports 00002800-0000ffff
[root at localhost ~]# cat /proc/cmdline 
BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.18-8.el5 root=/dev/VolGroup00/LogVol00 
rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug acpi=debug 3 ro
[root at localhost ~]# cat benkexec
#!/bin/bash
echo 15 > /proc/sys/kernel/printk
kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5 --append="root=/dev/VolGroup0
0/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug acpi=debug 3 r
o" --initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img 
[root at localhost ~]# ./benkexec
[root at localhost ~]# kexec -e
md: stopping all md devices.

Taking down system, will reboot
Synchronizing SCSI cache for disk sda: 
ACPI: PCI interrupt for device 0000:0a:01.1 disabled
GSI 73 (level, low) -> CPU 0 (0x0000) vector 54 unregistered
ACPI: PCI interrupt for device 0000:0a:01.0 disabled
GSI 72 (level, low) -> CPU 0 (0x0000) vector 53 unregistered
Starting new kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ia64-crash-screencap.jpg
Type: image/jpeg
Size: 55665 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/kexec/attachments/20070708/2fba8ca2/attachment-0001.jpg 

From nanhai.zou at intel.com  Sun Jul  8 21:29:40 2007
From: nanhai.zou at intel.com (Zou, Nanhai)
Date: Mon, 9 Jul 2007 09:29:40 +0800
Subject: kexec fails (pretty often)
In-Reply-To: <32209efe0707081045w7f110b37h92f385d9103d49ab@mail.gmail.com>
Message-ID: <10EA09EFD8728347A513008B6B0DA77A01751443@pdsmsx411.ccr.corp.intel.com>

> -----Original Message-----
> From: Natalie Protasevich [mailto:protasnb at gmail.com]
> Sent: 2007?7?9? 1:45
> To: Zou, Nanhai
> Cc: Luck, Tony; Kexec Mailing List; Horms
> Subject: Re: kexec fails (pretty often)
> 
> On 7/3/07, Natalie Protasevich <protasnb at gmail.com> wrote:
> > On 04 Jul 2007 08:29:39 +0800, Zou Nan hai <nanhai.zou at intel.com> wrote:
> > > On Wed, 2007-07-04 at 04:24, Eric W. Biederman wrote:
> > > > "Natalie Protasevich" <protasnb at gmail.com> 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)?
> > > > >        ;;
> > > > > ...
> > > > >
> > >
> > >
> > > Hi,
> > >
> > > Is the problem reproducible? Is there any special configuration or kexec
> > > command line option to reproduce it?
> > > On which platform and which version of kernel did you see the issue?
> > >
> > > It looks like there may be something wrong with the memory map setting
> > > of the second kernel.
> > > Can you send me copies of /proc/iomem of the first kernel and the second
> > > kernel?
> > >
> >
> > Thanks! I will try to get as much information as I can.
> > It is 100 % reproducible, but intermittent - another words happens
> > with each run, but not predictably (I will get more precise scenario).
> > This is a large ES7000 server with up to 512 processors, I will find
> > out if this happens with large configuration or any.
> > Kernel is the SLES10 or RHEL4U5, they use both.
> > I will provide the iomem, not sure how soon - either tomorrow or after
> > the holiday...
> >
> Zou,
> 
> I got this information. Actually the situation is even worse than I imagined.
> 
> According to Ben who is working on this those are:
> 
> --------------------
> "To sum up what happens, I do this using the default kernel command line
> (and also one with "debug console=uart,io,0x3f8,115200n8 console=tty0"
> added to it):
> 
> # kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5
> --append=`cat /proc/cmdline`
> --initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img
> 
> # kexec -e
> 
> The old kernel shuts down and boots the new one successfully, but, the
> new kernel causes a fault during its boot. I can't positively identify
> the exact spot it crashes because the serial output stops. Going by the
> screen, it is either during or immediately after the ACPI system tries
> to detect all of the CPUs. On a couple occasions I've seen it spit out
> something along the lines of "EFI Time driver" before it blanks the
> screen out, but it does it very quickly and the Raritan doesn't update
> fast enough, even if I'm sitting at the cold floor display.
> 
> The system is configured with a single CPU, as multiple CPUs cause a
> different error, something along the lines of "huh? CPU #0x200 is
> already present" - but this also happened on the system without the
> capacitor fix. Turning on and off hyperthreading doesn't seem to matter
> either.
> 
> Here is entire log and a screen capture of the last things that
> show up on the video console. The /proc/iomem contents are at line 460
> in the log, and the kexec I used is at the very end. The second kernel
> doesn't get far enough to enter any commands, so I'm
> afraid I can't get you the /proc/iomem for that."
> --------------
> 
> Please advise where he can look to analyse this.
> Thanks!
> --Natalie


>From the log it is very hard to tell what is going wrong.
Is the "acpi=debug" in command line intend to be there?
Could you try latest base kernel? 
Also could you test if "kexec -p" works?

Thanks
Zou Nan hai


From protasnb at gmail.com  Sun Jul  8 21:45:56 2007
From: protasnb at gmail.com (Natalie Protasevich)
Date: Sun, 8 Jul 2007 18:45:56 -0700
Subject: kexec fails (pretty often)
In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A01751443@pdsmsx411.ccr.corp.intel.com>
References: <32209efe0707081045w7f110b37h92f385d9103d49ab@mail.gmail.com>
	<10EA09EFD8728347A513008B6B0DA77A01751443@pdsmsx411.ccr.corp.intel.com>
Message-ID: <32209efe0707081845y4141a363ic3a0a013ff6d527d@mail.gmail.com>

> > > > > > 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)?
> > > > > >        ;;
> > > > > > ...
> > > > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Is the problem reproducible? Is there any special configuration or kexec
> > > > command line option to reproduce it?
> > > > On which platform and which version of kernel did you see the issue?
> > > >
> > > > It looks like there may be something wrong with the memory map setting
> > > > of the second kernel.
> > > > Can you send me copies of /proc/iomem of the first kernel and the second
> > > > kernel?
> > > >
> > >
> > > Thanks! I will try to get as much information as I can.
> > > It is 100 % reproducible, but intermittent - another words happens
> > > with each run, but not predictably (I will get more precise scenario).
> > > This is a large ES7000 server with up to 512 processors, I will find
> > > out if this happens with large configuration or any.
> > > Kernel is the SLES10 or RHEL4U5, they use both.
> > > I will provide the iomem, not sure how soon - either tomorrow or after
> > > the holiday...
> > >
> > Zou,
> >
> > I got this information. Actually the situation is even worse than I imagined.
> >
> > According to Ben who is working on this those are:
> >
> > --------------------
> > "To sum up what happens, I do this using the default kernel command line
> > (and also one with "debug console=uart,io,0x3f8,115200n8 console=tty0"
> > added to it):
> >
> > # kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5
> > --append=`cat /proc/cmdline`
> > --initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img
> >
> > # kexec -e
> >
> > The old kernel shuts down and boots the new one successfully, but, the
> > new kernel causes a fault during its boot. I can't positively identify
> > the exact spot it crashes because the serial output stops. Going by the
> > screen, it is either during or immediately after the ACPI system tries
> > to detect all of the CPUs. On a couple occasions I've seen it spit out
> > something along the lines of "EFI Time driver" before it blanks the
> > screen out, but it does it very quickly and the Raritan doesn't update
> > fast enough, even if I'm sitting at the cold floor display.
> >
> > The system is configured with a single CPU, as multiple CPUs cause a
> > different error, something along the lines of "huh? CPU #0x200 is
> > already present" - but this also happened on the system without the
> > capacitor fix. Turning on and off hyperthreading doesn't seem to matter
> > either.
> >
> > Here is entire log and a screen capture of the last things that
> > show up on the video console. The /proc/iomem contents are at line 460
> > in the log, and the kexec I used is at the very end. The second kernel
> > doesn't get far enough to enter any commands, so I'm
> > afraid I can't get you the /proc/iomem for that."
> > --------------
> >
> > Please advise where he can look to analyse this.
> > Thanks!
> > --Natalie
>
>
> From the log it is very hard to tell what is going wrong.
> Is the "acpi=debug" in command line intend to be there?
> Could you try latest base kernel?
> Also could you test if "kexec -p" works?
>
I will ask them to run kexec -p, I think he intended to do apic=debug,
will mention that either ...
I see that they load the same kernel as the first one. It is a good
idea - to test with latest vanilla (2.6.22 as of today) and see if the
problem still there.
Thanks, I will pass on information to you later on as it becomes available.
Regards,
--Natalie


From bwalle at suse.de  Mon Jul  9 05:21:54 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Mon, 9 Jul 2007 11:21:54 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070706145804.GA31409@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
Message-ID: <20070709092154.GA19705@suse.de>

Hello,

* Dan Aloni <da-x at monatomic.org> [2007-07-06 16:58]:
> 
> Redhat has a makedumpinfo util which they intend to use as slim
> kernel-version-independent utility on kdump rootfs in order to
> save /proc/vmcore in a compact manner.

I think you mean makedumpfile, don't you?

> A patch that I am working on will make it possible to integrate
> the output of 'makedumpinfo -g' into vmlinux as the final build
> stage of the kernel. This information will be presented itself
> as /proc/kcore.info for the first kernel throughout its entire
> execution.

That sounds good. But I doubt that kernel developers like the idea of
needing another utility in the build process ...

> Then inside initramfs of the first kernel, a small 
> util will modify the vmlinux file of the kdump kernel before it
> gets loaded so that another special file appearing as 
> /proc/vmcore.info under the kdump kernel will present the same
> info. 

Where do you get the info from? If you're in the kdump initrd,
then the kdump kernel is already loaded. Do you want to attach the
info from the crashed kernel to the initrd of the kdump kernel?



Thanks,
   Bernhard


From da-x at monatomic.org  Mon Jul  9 07:41:31 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Mon, 9 Jul 2007 14:41:31 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070709092154.GA19705@suse.de>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
Message-ID: <20070709114131.GA18750@localdomain>

On Mon, Jul 09, 2007 at 11:21:54AM +0200, Bernhard Walle wrote:
> Hello,
> 
> * Dan Aloni <da-x at monatomic.org> [2007-07-06 16:58]:
> > 
> > Redhat has a makedumpinfo util which they intend to use as slim
> > kernel-version-independent utility on kdump rootfs in order to
> > save /proc/vmcore in a compact manner.
> 
> I think you mean makedumpfile, don't you?

Yes, a typo, sorry.

> > A patch that I am working on will make it possible to integrate
> > the output of 'makedumpinfo -g' into vmlinux as the final build
> > stage of the kernel. This information will be presented itself
> > as /proc/kcore.info for the first kernel throughout its entire
> > execution.
> 
> That sounds good. But I doubt that kernel developers like the idea of
> needing another utility in the build process ...

I don't think it would add much complexity to build process as it 
is now, just like the other tools that transparently do post-linking 
modifications. As far as the developer is concerned, there's just
the vmlinux and/or bzImage files that get emitted at the end.

> > Then inside initramfs of the first kernel, a small 
> > util will modify the vmlinux file of the kdump kernel before it
> > gets loaded so that another special file appearing as 
> > /proc/vmcore.info under the kdump kernel will present the same
> > info. 
> 
> Where do you get the info from? If you're in the kdump initrd,
> then the kdump kernel is already loaded. Do you want to attach the
> info from the crashed kernel to the initrd of the kdump kernel?

Not exactly. Let me describe the procedure in greater detail.
Basically, it would go like this:

1. <normal bootloader boot>
2. <normal initramfs>
3. embed_configfile /proc/kcore.info /vmlinux-kdump
4. kexec -l vmlinux-kdump <....>
5. <boot continues>
6. <crash>
7. <kdump kernel boot>
8. <kdump initramfs runs>
9. makedumpfile -i /proc/vmcore.info <....>

NOTES:
** in step 3 embed_configfile modifies vmlinux-kdump in place, 
   copying /proc/kcore.info into the data section of the vmlinux-kdump 
   at certain symbol (e.g. 'char core_info[0x1000]').
** in step 9 that data section variable (e.g. core_info) which was 
   originally holds the content of /proc/kcore.info is being presented 
   as /proc/vmcore.info for the util to use.

To complete the picture, at the final build stage of vmlinux we 
would have this:

makedumpfile -g vmlinux.configfile -x vmlinuxx
embed_configfile vmlinux.configfile vmlinux
rm vmlinux.configfile

BTW I think there could be a confusion between makedumpfile's 
CONFIGFILE and the .config file, so we should pick a different 
name for it...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From bwalle at suse.de  Mon Jul  9 16:49:38 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Mon, 9 Jul 2007 22:49:38 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070709114131.GA18750@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
Message-ID: <20070709204938.GA21663@suse.de>

Hi,

* Dan Aloni <da-x at monatomic.org> [2007-07-09 13:41]:
> > > A patch that I am working on will make it possible to integrate
> > > the output of 'makedumpinfo -g' into vmlinux as the final build
> > > stage of the kernel. This information will be presented itself
> > > as /proc/kcore.info for the first kernel throughout its entire
> > > execution.
> > 
> > That sounds good. But I doubt that kernel developers like the idea of
> > needing another utility in the build process ...
> 
> I don't think it would add much complexity to build process as it 
> is now, just like the other tools that transparently do post-linking 
> modifications. As far as the developer is concerned, there's just
> the vmlinux and/or bzImage files that get emitted at the end.

I didn't complain about the complexity but about the requirement of an
additional tool. However, I think it will be configurable.

> > > Then inside initramfs of the first kernel, a small 
> > > util will modify the vmlinux file of the kdump kernel before it
> > > gets loaded so that another special file appearing as 
> > > /proc/vmcore.info under the kdump kernel will present the same
> > > info. 
> > 
> > Where do you get the info from? If you're in the kdump initrd,
> > then the kdump kernel is already loaded. Do you want to attach the
> > info from the crashed kernel to the initrd of the kdump kernel?
> 
> Not exactly. Let me describe the procedure in greater detail.
> Basically, it would go like this:
> 
> 1. <normal bootloader boot>
> 2. <normal initramfs>
> 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> 4. kexec -l vmlinux-kdump <....>
> 5. <boot continues>
> 6. <crash>
> 7. <kdump kernel boot>
> 8. <kdump initramfs runs>
> 9. makedumpfile -i /proc/vmcore.info <....>

I don't see why an additional tool would be needed here. kexec already
modifies symbols, so why not adding the functionality into kexec? The
advantage would be that there's no on-disk modification necessary.

Another issue: Some parameters of makedumpfile (currently the page
size) are read from the running system. If you build the configuration
file while building the kernel, you always have the .config which
contains the page size. So it would be possible to extend the
makedumpfile utility to read that parts from a .config, and that would
remove a dependency that page size of the running kernel matches the
page size of the building kernel. On IA64, that's not always the case.

> BTW I think there could be a confusion between makedumpfile's 
> CONFIGFILE and the .config file, so we should pick a different 
> name for it...

Aggreed. Your suggestion? :)


Thanks,
   Bernhard


From oomichi at mxs.nes.nec.co.jp  Mon Jul  9 23:13:15 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Tue, 10 Jul 2007 12:13:15 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070706132814.GA7079@suse.de>
References: <20070706132814.GA7079@suse.de>
Message-ID: <20070710121315oomichi@mail.jp.nec.com>


Hi,

On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni <da-x at monatomic.org> wrote:
> On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > Hello,
> > 
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a specific
> > string or something like that which can fail on random memory.
> > 
> > Would it make sense to add a ELF PT_NOTE section in the vmcore?
> > 
> > Thanks for input!

(CONFIGFILE means makedumpfile's config file.)

makedumpfile checks kernel version by reading system_utsname.release
from /proc/vmcore, as you know. If the release and OSRELEASE in CONFIGFILE
don't match, makedumpfile fails.

Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
In the kernel building process, distributors need to make CONFIGFILE
on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
may be an older kernel. So OSRELEASE should be modified to the building
kernel version by hand, but it is not smart.

To solve this problem, I'm proposing 2 plans.
Could you give me your opinion ?

Plan 1:
  A new option [--osrelease="string"] is added.
  The OSRELEASE of CONFIGFILE is overwritten by "string".
  In the kernel building process, distributors should specify "string"
  as the building kernel version.

Plan2:
  Remove the OSRELEASE from CONFIGFILE.
  Instead of checking the OSRELEASE, makedumpfile only checks whether the
  area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
  is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
  "system_utsname" must not point to the correct area in most cases.
  Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
  But I think there are not any problems because old makedumpfile will not
  read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
  the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
  will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
  should be updated with CONFIGFILE.


I'd like to change the name of CONFIGFILE to mkdfinfo.


Thanks
Ken'ichi Ohmichi


From da-x at monatomic.org  Tue Jul 10 00:45:46 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 07:45:46 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070709204938.GA21663@suse.de>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070709204938.GA21663@suse.de>
Message-ID: <20070710044546.GA2240@localdomain>

On Mon, Jul 09, 2007 at 10:49:38PM +0200, Bernhard Walle wrote:
> Hi,
> 
> * Dan Aloni <da-x at monatomic.org> [2007-07-09 13:41]:
> > > > A patch that I am working on will make it possible to integrate
> > > > the output of 'makedumpinfo -g' into vmlinux as the final build
> > > > stage of the kernel. This information will be presented itself
> > > > as /proc/kcore.info for the first kernel throughout its entire
> > > > execution.
> > > 
> > > That sounds good. But I doubt that kernel developers like the idea of
> > > needing another utility in the build process ...
> > 
> > I don't think it would add much complexity to build process as it 
> > is now, just like the other tools that transparently do post-linking 
> > modifications. As far as the developer is concerned, there's just
> > the vmlinux and/or bzImage files that get emitted at the end.
> 
> I didn't complain about the complexity but about the requirement of an
> additional tool. However, I think it will be configurable.

Yes, I suppose it should be.
 
> > > > Then inside initramfs of the first kernel, a small 
> > > > util will modify the vmlinux file of the kdump kernel before it
> > > > gets loaded so that another special file appearing as 
> > > > /proc/vmcore.info under the kdump kernel will present the same
> > > > info. 
> > > 
> > > Where do you get the info from? If you're in the kdump initrd,
> > > then the kdump kernel is already loaded. Do you want to attach the
> > > info from the crashed kernel to the initrd of the kdump kernel?
> > 
> > Not exactly. Let me describe the procedure in greater detail.
> > Basically, it would go like this:
> > 
> > 1. <normal bootloader boot>
> > 2. <normal initramfs>
> > 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> > 4. kexec -l vmlinux-kdump <....>
> > 5. <boot continues>
> > 6. <crash>
> > 7. <kdump kernel boot>
> > 8. <kdump initramfs runs>
> > 9. makedumpfile -i /proc/vmcore.info <....>
> 
> I don't see why an additional tool would be needed here. kexec already
> modifies symbols, so why not adding the functionality into kexec? The
> advantage would be that there's no on-disk modification necessary.

Actually, 'embed_configfile /proc/kcore.info /vmlinux-kdump' makes
no on-disk modification, since it is all contained in initramfs (we
step out of initramfs in stage 5). 

BTW another option would be containing the whole CONFIGFILE as a 
vmlinux-specific ELF note, to be easily read from /proc/vmcore.
You'd still need some util like embed_configfile at build time 
in order to integrate it, and you'd also need to modify 
makedumpfile so it can use it. Actually this sounds quite better
to me. I'll try to prepare patches both for makedumpfile and the 
kernel and see how easy it is.

> Another issue: Some parameters of makedumpfile (currently the page
> size) are read from the running system. If you build the configuration
> file while building the kernel, you always have the .config which
> contains the page size. So it would be possible to extend the
> makedumpfile utility to read that parts from a .config, and that would
> remove a dependency that page size of the running kernel matches the
> page size of the building kernel. On IA64, that's not always the case.

That needs to be changed.. the part in makedumpfile that generates 
the CONFIGFILE shouldn't depend on the running kernel at all. As 
Ken'ichi suggests we don't need to have 'OSRELEASE=' in the 
CONFIGFILE (instead, peeking inside init_uts_ns from /proc/vmcore
is enough). For PAGESIZE, it can be replaced by readmem() of some
variable such as:

         unsigned int image_page_size = PAGE_SIZE;

With the system I propose for generation and delivery of the 
CONFIGFILE, it would be impossible to pass an incorrect CONFIGFILE
since the kernel will already contain its own CONFIGFILE generated
during build time (assuming it didn't get corrupted in the crash,
it's quite far-fetched...).

> > BTW I think there could be a confusion between makedumpfile's 
> > CONFIGFILE and the .config file, so we should pick a different 
> > name for it...
> 
> Aggreed. Your suggestion? :)

Ken'ichi's "mkdfinfo" works for me.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From vgoyal at in.ibm.com  Tue Jul 10 01:52:59 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 10 Jul 2007 11:22:59 +0530
Subject: [PATCH] Determine ELF32/ELF64 automatically on i386
In-Reply-To: <20070703161207.GA5070@suse.de>
References: <20070702131541.GA6084@suse.de> <20070703161207.GA5070@suse.de>
Message-ID: <20070710055259.GA5471@in.ibm.com>

On Tue, Jul 03, 2007 at 06:12:07PM +0200, Bernhard Walle wrote:
> 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.
> 

Makes sense to me. No need to generate 64bit ELF headers on systems
having less than 4G of memory. gdb runs into issues with 64bit ELF headers
on 32bit machines.

> +++ b/kexec/arch/i386/kexec-x86.h
> @@ -2,8 +2,12 @@
>  #define KEXEC_X86_H
> 
>  #define MAX_MEMORY_RANGES 64
> -#define CORE_TYPE_ELF32 1
> -#define CORE_TYPE_ELF64 2
> +
> +enum CoreType {
> +	CORE_TYPE_UNDEF = 0,
> +	CORE_TYPE_ELF32 = 1,
> +	CORE_TYPE_ELF64 = 2
> +};
> 

I think we can avoid mixed case in "CoreType" and use something like
"coretype".

Thanks
Vivek


From vgoyal at in.ibm.com  Tue Jul 10 02:36:24 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 10 Jul 2007 12:06:24 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070706132814.GA7079@suse.de>
References: <20070706132814.GA7079@suse.de>
Message-ID: <20070710063624.GB5471@in.ibm.com>

On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> Hello,
> 
> does anybody know a _reliable_ way to determine the version the kernel
> that produced a vmcore file? This means not scanning for a specific
> string or something like that which can fail on random memory.
> 
> Would it make sense to add a ELF PT_NOTE section in the vmcore?
> 

To me it makes sense to append an ELF NOTE to vmcore which can uniquely
associate that vmcore with a particular vmlinux file (Some string
equivalent to the output of uname -a).

Interesting thing is that to find version of vmlinux, you will still be
doing <string | grep "some pattern">. Probably then we should append an
ELF note to vmlinux file also?

Thanks
Vivek


From vgoyal at in.ibm.com  Tue Jul 10 02:48:17 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 10 Jul 2007 12:18:17 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070706145804.GA31409@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
Message-ID: <20070710064817.GC5471@in.ibm.com>

On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > Hello,
> > 
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a specific
> > string or something like that which can fail on random memory.
> > 
> > Would it make sense to add a ELF PT_NOTE section in the vmcore?
> > 
> > Thanks for input!
> 
> (I'm sorry if this E-Mail needlessly turned into a long RFC 
> but I had to bring this up when I bumped into this question on 
> LKML)
> 
> Actually, instead of another ELF PT_NOTE section for this 
> information and other things, kdump is currently going into 
> another direction, described below.
> 
> Redhat has a makedumpinfo util which they intend to use as slim
> kernel-version-independent utility on kdump rootfs in order to
> save /proc/vmcore in a compact manner.
> 
> Normally makedumpinfo would require access to the vmlinux file 
> that the crashed kernel was originated from. However instead of 
> depending on vmlinux, it is possible to generate a small textual
> "CONFIGFILE" that looks like this, for example (generated using
> makedumpinfo -g):
> 
> OSRELEASE=2.6.20.3
> PAGESIZE=4096
> SYMBOL(mem_map)=ffffffff806cf5d8
> SYMBOL(init_uts_ns)=ffffffff805f8be0
> SYMBOL(_stext)=ffffffff80200f20
> SYMBOL(node_online_map)=ffffffff80651bc0
> SYMBOL(contig_page_data)=ffffffff80600e80
> SIZE(page)=56
> SIZE(pglist_data)=3712
> SIZE(zone)=1152
> SIZE(free_area)=24
> SIZE(list_head)=16
> OFFSET(page.flags)=0
> OFFSET(page._count)=8
> OFFSET(page.mapping)=24
> OFFSET(page.lru)=40
> OFFSET(pglist_data.node_zones)=0
> OFFSET(pglist_data.nr_zones)=3576
> OFFSET(pglist_data.node_mem_map)=3584
> OFFSET(pglist_data.node_start_pfn)=3600
> OFFSET(pglist_data.node_spanned_pages)=3616
> OFFSET(zone.free_pages)=0
> OFFSET(zone.free_area)=408
> OFFSET(zone.vm_stat)=872
> OFFSET(zone.spanned_pages)=1064
> OFFSET(free_area.free_list)=0
> OFFSET(list_head.next)=0
> OFFSET(list_head.prev)=8
> LENGTH(zone.free_area)=11
> SRCFILE(pud_t)=include/asm/page.h
> 
> It contains enough information in order to make a compact kernel
> dump (makedumpinfo needs to go over the struct page arrays). As
> you see, it also contains the kernel version.
> 

But this will not solve Bernhard's problem where looking at a vmcore
he wants to know which vmlinux (kernel version with time stamp) has
generated this vmcore. So adding a ELF NOTE should help.

> However, this file needs to be passed somehow to the rootfs
> of the kdump kernel. This poses a chicken-and-egg problem on 
> my setup where the initramfs of the first kernel contains 
> a staticlu linked version of the kexec executable along with a
> kdump kernel to be loaded before mount rootfs and running 
> init. 
> 

Why are you loading kdump kernel from first kernel's initramfs?
I guess to enable the dump capture as soon as possible so if some
driver panics() you can capture the dump?

Can't we modify the initramfs generation process (mkinitrd) to take
care of this situation?. By the way, how is second kernel's initramfs
is generated currently? The moment we start packing a file which contains
the debuginfo for first kernel, initramfs of second kernel becomes dependent
on first kernel and to me its not a good approach.

A dump kernel and its initrd should be independent of the crashing kernel.

Neil/Keni'chi, how is this taken care in current RHEL5 build? Is second
kernel's initramfs dependent on first kernel if one is doing filtering
in second kernel from initramfs?

Thanks
Vivek


From protasnb at gmail.com  Tue Jul 10 01:55:18 2007
From: protasnb at gmail.com (Natalie Protasevich)
Date: Mon, 9 Jul 2007 23:55:18 -0600
Subject: kexec fails (pretty often)
In-Reply-To: <32209efe0707081845y4141a363ic3a0a013ff6d527d@mail.gmail.com>
References: <32209efe0707081045w7f110b37h92f385d9103d49ab@mail.gmail.com>
	<10EA09EFD8728347A513008B6B0DA77A01751443@pdsmsx411.ccr.corp.intel.com>
	<32209efe0707081845y4141a363ic3a0a013ff6d527d@mail.gmail.com>
Message-ID: <32209efe0707092255n5d87fd70j369919a5ec8094c2@mail.gmail.com>

On 7/8/07, Natalie Protasevich <protasnb at gmail.com> wrote:
> > > > > > > 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)?
> > > > > > >        ;;
> > > > > > > ...
> > > > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Is the problem reproducible? Is there any special configuration or kexec
> > > > > command line option to reproduce it?
> > > > > On which platform and which version of kernel did you see the issue?
> > > > >
> > > > > It looks like there may be something wrong with the memory map setting
> > > > > of the second kernel.
> > > > > Can you send me copies of /proc/iomem of the first kernel and the second
> > > > > kernel?
> > > > >
> > > >
> > > > Thanks! I will try to get as much information as I can.
> > > > It is 100 % reproducible, but intermittent - another words happens
> > > > with each run, but not predictably (I will get more precise scenario).
> > > > This is a large ES7000 server with up to 512 processors, I will find
> > > > out if this happens with large configuration or any.
> > > > Kernel is the SLES10 or RHEL4U5, they use both.
> > > > I will provide the iomem, not sure how soon - either tomorrow or after
> > > > the holiday...
> > > >
> > > Zou,
> > >
> > > I got this information. Actually the situation is even worse than I imagined.
> > >
> > > According to Ben who is working on this those are:
> > >
> > > --------------------
> > > "To sum up what happens, I do this using the default kernel command line
> > > (and also one with "debug console=uart,io,0x3f8,115200n8 console=tty0"
> > > added to it):
> > >
> > > # kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5
> > > --append=`cat /proc/cmdline`
> > > --initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img
> > >
> > > # kexec -e
> > >
> > > The old kernel shuts down and boots the new one successfully, but, the
> > > new kernel causes a fault during its boot. I can't positively identify
> > > the exact spot it crashes because the serial output stops. Going by the
> > > screen, it is either during or immediately after the ACPI system tries
> > > to detect all of the CPUs. On a couple occasions I've seen it spit out
> > > something along the lines of "EFI Time driver" before it blanks the
> > > screen out, but it does it very quickly and the Raritan doesn't update
> > > fast enough, even if I'm sitting at the cold floor display.
> > >
> > > The system is configured with a single CPU, as multiple CPUs cause a
> > > different error, something along the lines of "huh? CPU #0x200 is
> > > already present" - but this also happened on the system without the
> > > capacitor fix. Turning on and off hyperthreading doesn't seem to matter
> > > either.
> > >
> > > Here is entire log and a screen capture of the last things that
> > > show up on the video console. The /proc/iomem contents are at line 460
> > > in the log, and the kexec I used is at the very end. The second kernel
> > > doesn't get far enough to enter any commands, so I'm
> > > afraid I can't get you the /proc/iomem for that."
> > > --------------
> > >
> > > Please advise where he can look to analyse this.
> > > Thanks!
> > > --Natalie
> >
> >
> > From the log it is very hard to tell what is going wrong.
> > Is the "acpi=debug" in command line intend to be there?
> > Could you try latest base kernel?
> > Also could you test if "kexec -p" works?
> >
> I will ask them to run kexec -p, I think he intended to do apic=debug,
> will mention that either ...
> I see that they load the same kernel as the first one. It is a good
> idea - to test with latest vanilla (2.6.22 as of today) and see if the
> problem still there.
> Thanks, I will pass on information to you later on as it becomes available.
> Regards,
> --Natalie
>
Nanhai,
That was really great idea - everything worked with 2.6.22! They still
get SMP problem, I think this might be something with APIC mode it
gets into with the second kernel. Now they can take a trace at least.
Bad FSB transaction seems to be unrelated to kexec.
Thanks for your help! (I am attaching traces FYI)
Regards,
--Natalie
-------------- next part --------------
Linux version 2.6.18-8.el5 (brewbuilder at hitachi-1.build.redhat.com) (gcc version
 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:16:09 EST 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
Number of logical nodes in system = 1
Number of memory chunks in system = 2
rsvd_region[0]: [0xe000000001000000, 0xe000000001000120)
rsvd_region[1]: [0xe000000004000000, 0xe000000004d54c28)
rsvd_region[2]: [0xe000001006be0010, 0xe000001006be0060)
rsvd_region[3]: [0xe000001006be3f79, 0xe000001006be4010)
rsvd_region[4]: [0xe000001006be7000, 0xe000001006f95fa9)
rsvd_region[5]: [0xe000001006f9c010, 0xe000001006f9c970)
rsvd_region[6]: [0xffffffffffffffff, 0xffffffffffffffff)
Initial ramdisk at: 0xe000001006be7000 (3862441 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4189178
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.18-8.el5 root=/dev
/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic
=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Linux version 2.6.18-8.el5 (brewbuilder at hitachi-1.build.redhat.com) (gcc version
 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:16:09 EST 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP (v002 PTLTD                                 ) @ 0x00000000000f7320
ACPI: XSDT (v001 PTLTD  	 XSDT   0x06040000  LTP 0x00000000) @ 0x00000000
fcb4aa16
ACPI: FADT (v003 UNISYS ZORRO    0x06040000 PTL  0x000f4240) @ 0x00000000fcba2cb
4
ACPI: OEM1 (v001 UNISYS   OEM1   0x06040000  LTP 0x00000000) @ 0x00000000fcba2da
8
ACPI: SRAT (v001 UNISYS   SRAT   0x06040000  LTP 0x00000000) @ 0x00000000fcba2dd
8
ACPI: IPPT (v001 UNISYS   IPPT   0x06040000  LTP 0x00000000) @ 0x00000000fcba2e6
8
ACPI: MADT (v001 PTLTD  	 APIC   0x06040000  LTP 0x00000000) @ 0x00000000
fcba2ea2
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x00000000fcba2f8
8
ACPI: SPCR (v001 PTLTD  $UCRTBL$ 0x06040000 PTL  0x00000001) @ 0x00000000fcba2fb
0
ACPI: DSDT (v001  Intel  870 SMP 0x06040000 MSFT 0x03000000) @ 0x000000000000000
0
Number of logical nodes in system = 1
Number of memory chunks in system = 2
rsvd_region[0]: [0xe000000001000000, 0xe000000001000120)
rsvd_region[1]: [0xe000000004000000, 0xe000000004d54c28)
rsvd_region[2]: [0xe000001006be0010, 0xe000001006be0060)
rsvd_region[3]: [0xe000001006be3f79, 0xe000001006be4010)
rsvd_region[4]: [0xe000001006be7000, 0xe000001006f95fa9)
rsvd_region[5]: [0xe000001006f9c010, 0xe000001006f9c970)
rsvd_region[6]: [0xffffffffffffffff, 0xffffffffffffffff)
Initial ramdisk at: 0xe000001006be7000 (3862441 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
On node 0 totalpages: 4189178
  DMA zone: 249133 pages, LIFO batch:7
  Normal zone: 3940045 pages, LIFO batch:7
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4189178
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.18-8.el5 root=/dev
/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic
=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Placing software IO TLB between 0x8eb8000 - 0xceb8000
Memory: 66595680k/67026848k available (6259k code, 448672k reserved, 4066k data,
 656k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 3194.88 BogoMIPS (lpj=1597440)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Dentry cache hash table entries: 8388608 (order: 12, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 11, 33554432 bytes)
Mount-cache hash table entries: 1024
ACPI: Core revision 20060707
Boot processor id 0x0/0x0
Brought up 1 CPUs
Total of 1 processors activated (3194.88 BogoMIPS).
sizeof(vma)=176 bytes
sizeof(page)=56 bytes
sizeof(inode)=568 bytes
sizeof(dentry)=216 bytes
sizeof(ext3inode)=776 bytes
sizeof(buffer_head)=96 bytes
sizeof(skbuff)=240 bytes
checking if image is initramfs... it is
Freeing initrd memory: 3760kB freed
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: Device [MBDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MBDV] (0000:ff)
ACPI: Device [MEDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MEDV] (0000:fe)
ACPI: PCI Root Bridge [S0H0] (0000:00)
PCI quirk: region 0d00-0d7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0d80-0dbf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 6 10 *11 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0.PCI1._PRT]
ACPI: PCI Root Bridge [S0H1] (0000:02)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI1._PRT]
ACPI: PCI Root Bridge [S0H2] (0000:09)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 9 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 8388608 (order: 13, 134217728 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 8388608 bind 65536)
TCP reno registered
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
audit: initializing netlink socket (disabled)
audit(1183988924.630:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 16384 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 47634A68C1FD4634
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x1
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x2
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x3
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x4
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x5
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x6
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x7
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x8
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0x9
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xa
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xb
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xc
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xd
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xe
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not pres
ent [20060707]
ACPI: Getting cpuindex for acpiid 0xf
EFI Time Services Driver v0.4
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled
00:06: ttyS0 at I/O 0x3f8 (irq = 44) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Device 0000:00:1f.1 not available because of resource collisions
GSI 18 (level, low) -> CPU 0 (0x0000) vector 48
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 48
ICH4: BIOS configuration fixed.
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x0880-0x0887, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x0888-0x088f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-6750A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 34
Probing IDE interface ide1...
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
ide-floppy driver 0.99.newide
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EFI Variables Facility v0.08 2004-May-17
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Adding console on ttyS0 at I/O port 0x3f8 (options '115200n8')
Freeing unused kernel memory: 656kB freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
GSI 16 (level, low) -> CPU 0 (0x0000) vector 49
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 49
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 49, io base 0x00000800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
GSI 19 (level, low) -> CPU 0 (0x0000) vector 50
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 50
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 50, io base 0x00000820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 48
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 48, io base 0x00000840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Loading ohci-hcd.ko module
usb 2-1: new full speed USB device using uhci_hcd and address 2
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
Loading ehci-hcd.ko module
GSI 23 (level, low) -> CPU 0 (0x0000) vector 51
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 51
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: slot 0000:00:1d.7 has incorrect PCI cache line size of 0 bytes, correcting 
to 128
ehci_hcd 0000:00:1d.7: irq 51, io mem 0xf7fffc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
Loading jbd.ko module
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_sas.ko module
Loading mptbase.ko module
Fusion MPT base driver 3.04.02
Copyright (c) 1999-2005 LSI Logic Corporation
usb 2-1: device not accepting address 2, error -71
Loading mptscsih.ko module
Loading mptsas.ko module
Fusion MPT SAS Host driver 3.04.02
GSI 48 (level, low) -> CPU 0 (0x0000) vector 52
ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 52
mptbase: Initiating ioc0 bringup
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
input: Unisys Corporation as /class/input/input0
input: USB HID v1.01 Keyboard [Unisys Corporation] on usb-0000:00:1d.1-1
input: Unisys Corporation as /class/input/input1
input: USB HID v1.01 Mouse [Unisys Corporation] on usb-0000:00:1d.1-1
usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input2
input: USB HID v1.00 Keyboard [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-
0000:00:1d.2-1
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input3
input: USB HID v1.00 Mouse [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-000
0:00:1d.2-1
ioc0: SAS1068: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1068, FwRev=010a0000h, Ports=1, MaxQ=511, IRQ=52
  Vendor: FUJITSU   Model: MAV2073RC         Rev: 0109
  Type:   Direct-Access                      ANSI SCSI revision: 03
SCSI device sda: 140625000 512-byte hdwr sectors (72000 MB)
sda: Write Protect is off
sda: Mode Sense: bf 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 140625000 512-byte hdwr sectors (72000 MB)
sda: Write Protect is off
sda: Mode Sense: bf 00 00 08
SCSI device sda: drive cache: write back
 sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-09-14) initialised: dm-devel at redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Waiting for driver initialization.
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1183988945.788:2): selinux=0 auid=4294967295
INIT: version 2.86 booting
		Welcome to Red Hat Enterprise Linux Server
		Press 'I' to enter interactive startup.
Setting clock  (utc): Mon Jul  9 09:49:08 EDT 2007 [  OK  ]
Starting udev: [  OK  ]
Loading default keymap (us): [  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Setting up Logical Volume Management:   /dev/hda: open failed: No medium found
  2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 155150/17039360 files, 2071536/17039360 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting background readahead: [  OK  ]
Checking for hardware changes [  OK  ]
Loading uscd driver...[  OK  ]
Starting uscm services...[  OK  ]
Starting uscr services...[  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
[  OK  ]
Bringing up interface eth1:  
Determining IP information for eth1... failed; no link present.  Check cable?
[FAILED]
Starting auditd: [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting portmap: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: [  OK  ]
Starting kdump:[FAILED]
Starting system message bus: [  OK  ]
Starting Bluetooth services:[  OK  ][  OK  ]
Mounting other filesystems:  [  OK  ]
Starting PC/SC smart card daemon (pcscd): [  OK  ]
Starting hidd: [  OK  ]
Starting autofs:  Loading autofs4: [  OK  ]
Starting automount: [  OK  ]
[  OK  ]
Starting acpi daemon: [  OK  ]
Starting hpiod: [  OK  ]
Starting hpssd: [  OK  ]
Starting cups: [  OK  ]
Starting sshd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting console mouse services: [  OK  ]
Starting crond: [  OK  ]
Starting xfs: [  OK  ]
Starting anacron: [  OK  ]
Starting atd: [  OK  ]
Starting salinfo_decode_all: [  OK  ]
Starting yum-updatesd: [  OK  ]
Starting Avahi daemon... [  OK  ]
Starting HAL daemon: [  OK  ]
Starting smartd: [  OK  ]

Red Hat Enterprise Linux Server release 5 (Tikanga)
Kernel 2.6.18-8.el5 on an ia64

localhost.localdomain login: root
Password: 
Last login: Fri Jul  6 10:07:27 on ttyS0
[root at localhost ~]# ech   cat /proc/iomem 
00000000-00000fff : System RAM
00001000-00089fff : System RAM
0008a000-0009ffff : System RAM
000a0000-000fffff : PCI Bus 0000:00
  000c0000-000fffff : reserved
00100000-03ffffff : System RAM
04000000-04d54fff : System RAM
  04000000-0461ce3f : Kernel code
  0461ce40-04d54c27 : Kernel data
04d55000-37dfffff : System RAM
37e00000-37efffff : reserved
37f00000-efffffff : System RAM
f2000000-f3ffffff : PCI Bus 0000:09
  f2e00000-f2ffffff : PCI Bus #0d
    f2effc00-f2effcff : 0000:0d:1f.0
  f3e00000-f3efffff : PCI Bus #0d
  f3f00000-f3ffffff : PCI Bus #0a
    f3fc0000-f3fdffff : 0000:0a:01.1
      f3fc0000-f3fdffff : e1000
    f3fe0000-f3ffffff : 0000:0a:01.0
      f3fe0000-f3ffffff : e1000
f4000000-f4ffffff : PCI Bus 0000:02
  f4f00000-f4ffffff : PCI Bus #06
    f4fec000-f4feffff : 0000:06:01.0
    f4ff0000-f4ffffff : 0000:06:01.0
f5000000-f7ffffff : PCI Bus 0000:00
  f6000000-f7efffff : PCI Bus #01
    f6000000-f6ffffff : 0000:01:01.0
    f7ef8000-f7efbfff : 0000:01:02.0
    f7efc000-f7efcfff : 0000:01:03.0
    f7efd000-f7efdfff : 0000:01:03.0
    f7efe800-f7efefff : 0000:01:02.0
    f7eff000-f7efffff : 0000:01:01.0
  f7fffc00-f7ffffff : 0000:00:1d.7
    f7fffc00-f7ffffff : ehci_hcd
f8000000-fc72bfff : System RAM
fc72c000-fcc65fff : reserved
fcc66000-fcca5fff : reserved
fcca6000-fcffffff : reserved
fd000000-fd2fffff : reserved
fd300000-fdec8fff : System RAM
fdec9000-fdedffff : System RAM
fdee0000-fdee7fff : reserved
fdee8000-fdeedfff : System RAM
fdeee000-fdffffff : reserved
fec02000-fec02fff : 0000:02:1c.0
fec03000-fec03fff : 0000:02:1e.0
fec04000-fec04fff : 0000:09:1c.0
fec05000-fec05fff : 0000:09:1e.0
ff000000-ff01ffff : reserved
ff42a000-ff469fff : reserved
ff800000-ffffffff : reserved
100000000-1006bdffff : System RAM
1006be0000-1006be5fff : System RAM
  1006be0010-1006be0060 : Boot parameter
1006be6000-1006be6fff : System RAM
1006be7000-1006f9ffff : System RAM
  1006f9c010-1006f9c970 : EFI Memory Map
1006fa0000-1006fa0fff : System RAM
1006fa1000-1006ffdfff : System RAM
1006ffe000-1007152fff : System RAM
1007153000-1007800fff : System RAM
1007801000-1007919fff : System RAM
100791a000-100791bfff : System RAM
100791c000-100791dfff : System RAM
100791e000-1007923fff : System RAM
1007924000-1007925fff : System RAM
1007926000-10079f9fff : System RAM
10079fa000-10079fafff : System RAM
10079fb000-10079fdfff : System RAM
10079fe000-1007cfbfff : System RAM
1007cfc000-1007d65fff : reserved
1007d66000-1007dcffff : System RAM
1007dd0000-1007dfdfff : System RAM
1007dfe000-1007e29fff : System RAM
1007e2a000-1007e2bfff : reserved
1007e2c000-1007e2dfff : System RAM
1007e2e000-1007e7dfff : reserved
1007e7e000-1007fb5fff : System RAM
1007fb6000-1007ffffff : reserved
ffffc000000-ffffc7fffff : PCI Bus 0000:00 I/O Ports 00000000-00001fff
ffffc800000-ffffc9ff7ff : PCI Bus 0000:02 I/O Ports 00002000-000027ff
ffffca00800-fffffffffff : PCI Bus 0000:09 I/O Ports 00002800-0000ffff
[root at localhost ~]# cat /proc/          ./  cat benkexec
#!/bin/bash
echo 15 > /proc/sys/kernel/printk
kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.18-8.el5 --append="root=/dev/VolGroup0
0/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic=debug 3 r
o" --initrd=/boot/efi/efi/redhat/initrd-2.6.18-8.el5.img 
[root at localhost ~]# ./benkexec 
[root at localhost ~]# kexec -e
md: stopping all md devices.

Taking down system, will reboot
Synchronizing SCSI cache for disk sda: 
ACPI: PCI interrupt for device 0000:0a:01.1 disabled
GSI 73 (level, low) -> CPU 0 (0x0000) vector 54 unregistered
ACPI: PCI interrupt for device 0000:0a:01.0 disabled
GSI 72 (level, low) -> CPU 0 (0x0000) vector 53 unregistered
Starting new kernel
-------------- next part --------------
Linux version 2.6.22ben (root at localhost.localdomain) (gcc version 4.1.1 20070105
 (Red Hat 4.1.1-52)) #1 SMP Mon Jul 9 10:15:01 EDT 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP 000F7320, 0024 (r2 PTLTD )
ACPI: XSDT FCB4AA16, 005C (r1 PTLTD  	 XSDT    6040000  LTP        0)
ACPI: FACP FCBA2CB4, 00F4 (r3 UNISYS ZORRO     6040000 PTL     F4240)
ACPI: DSDT FCB4AA72, 58242 (r1  Intel  870 SMP  6040000 MSFT  3000000)
ACPI: FACS FCBA4F00, 0040
ACPI: OEM1 FCBA2DA8, 0030 (r1 UNISYS   OEM1    6040000  LTP        0)
ACPI: SRAT FCBA2DD8, 0090 (r1 UNISYS   SRAT    6040000  LTP        0)
ACPI: IPPT FCBA2E68, 003A (r1 UNISYS   IPPT    6040000  LTP        0)
ACPI: APIC FCBA2EA2, 00E6 (r1 PTLTD  	 APIC    6040000  LTP        0)
ACPI: BOOT FCBA2F88, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
ACPI: SPCR FCBA2FB0, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
Number of logical nodes in system = 1
Number of memory chunks in system = 2
Initial ramdisk at: 0xe000001006be3000 (3870554 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
Zone PFN ranges:
  DMA          1024 ->   262144
  Normal     262144 ->  4202496
early_node_map[8] active PFN ranges
    0:     1024 ->    57216
    0:    57280 ->   245760
    0:   253952 ->   258507
    0:   259264 ->   260024
    0:   260026 ->   260027
    0:   262144 ->  4202303
    0:  4202330 ->  4202378
    0:  4202400 ->  4202477
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4175913
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.22ben root=/dev/Vo
lGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic=de
bug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Linux version 2.6.22ben (root at localhost.localdomain) (gcc version 4.1.1 20070105
 (Red Hat 4.1.1-52)) #1 SMP Mon Jul 9 10:15:01 EDT 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP 000F7320, 0024 (r2 PTLTD )
ACPI: XSDT FCB4AA16, 005C (r1 PTLTD  	 XSDT    6040000  LTP        0)
ACPI: FACP FCBA2CB4, 00F4 (r3 UNISYS ZORRO     6040000 PTL     F4240)
ACPI: DSDT FCB4AA72, 58242 (r1  Intel  870 SMP  6040000 MSFT  3000000)
ACPI: FACS FCBA4F00, 0040
ACPI: OEM1 FCBA2DA8, 0030 (r1 UNISYS   OEM1    6040000  LTP        0)
ACPI: SRAT FCBA2DD8, 0090 (r1 UNISYS   SRAT    6040000  LTP        0)
ACPI: IPPT FCBA2E68, 003A (r1 UNISYS   IPPT    6040000  LTP        0)
ACPI: APIC FCBA2EA2, 00E6 (r1 PTLTD  	 APIC    6040000  LTP        0)
ACPI: BOOT FCBA2F88, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
ACPI: SPCR FCBA2FB0, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
Number of logical nodes in system = 1
Number of memory chunks in system = 2
Entering add_active_range(0, 1024, 57216) 0 entries of 51200 used
Entering add_active_range(0, 57280, 245760) 1 entries of 51200 used
Entering add_active_range(0, 253952, 258507) 2 entries of 51200 used
Entering add_active_range(0, 259264, 260024) 3 entries of 51200 used
Entering add_active_range(0, 260026, 260027) 4 entries of 51200 used
Entering add_active_range(0, 262144, 4202303) 5 entries of 51200 used
Entering add_active_range(0, 4202330, 4202378) 6 entries of 51200 used
Entering add_active_range(0, 4202400, 4202477) 7 entries of 51200 used
Initial ramdisk at: 0xe000001006be3000 (3870554 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
Zone PFN ranges:
  DMA          1024 ->   262144
  Normal     262144 ->  4202496
early_node_map[8] active PFN ranges
    0:     1024 ->    57216
    0:    57280 ->   245760
    0:   253952 ->   258507
    0:   259264 ->   260024
    0:   260026 ->   260027
    0:   262144 ->  4202303
    0:  4202330 ->  4202378
    0:  4202400 ->  4202477
On node 0 totalpages: 4190272
  DMA zone: 892 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 249096 pages, LIFO batch:7
  Normal zone: 13467 pages used for memmap
  Normal zone: 3926817 pages, LIFO batch:7
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4175913
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.22ben root=/dev/Vo
lGroup00/LogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic=de
bug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Placing software IO TLB between 0x8f98000 - 0xcf98000
Memory: 66594224k/67025264k available (6383k code, 450128k reserved, 4234k data,
 672k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 3194.88 BogoMIPS (lpj=1597440)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Dentry cache hash table entries: 8388608 (order: 12, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 11, 33554432 bytes)
Mount-cache hash table entries: 1024
ACPI: Core revision 20070126
Boot processor id 0x0/0x0
Brought up 1 CPUs
Total of 1 processors activated (3194.88 BogoMIPS).
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: Device [MBDV] status [00000008]: functional but not present; setting prese
nt
ACPI: Device [MEDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MBDV] (0000:ff)
ACPI: PCI Root Bridge [MEDV] (0000:fe)
ACPI: PCI Root Bridge [S0H0] (0000:00)
PCI quirk: region 0d00-0d7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0d80-0dbf claimed by ICH4 GPIO
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0.PCI1._PRT]
ACPI: PCI Root Bridge [S0H1] (0000:02)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI1._PRT]
ACPI: PCI Root Bridge [S0H2] (0000:09)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *12
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 6 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 9 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 8388608 (order: 13, 201326592 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 8388608 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3760kB freed
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
audit: initializing netlink socket (disabled)
audit(1183991173.730:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 16384 bytes)
SELinux:  Registering netfilter hooks
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
EFI Time Services Driver v0.4
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled
?00:06: ttyS0 at I/O 0x3f8 (irq = 44) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Device 0000:00:1f.1 not available because of resource collisions
GSI 18 (level, low) -> CPU 0 (0x0000) vector 48
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 48
ICH4: BIOS configuration fixed.
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x0880-0x0887, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x0888-0x088f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-6750A, ATAPI CD/DVD-ROM drive
hda: selected mode 0x42
ide0 at 0x1f0-0x1f7,0x3f6 on irq 34
Probing IDE interface ide1...
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
EFI Variables Facility v0.08 2004-May-17
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Adding console on ttyS0 at I/O port 0x3f8 (options '115200n8')
Freeing unused kernel memory: 672kB freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
GSI 16 (level, low) -> CPU 0 (0x0000) vector 49
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 49
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 49, io base 0x00000800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
GSI 19 (level, low) -> CPU 0 (0x0000) vector 50
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 50
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 50, io base 0x00000820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 48
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 48, io base 0x00000840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Loading ohci-hcd.ko module
usb 2-1: new full speed USB device using uhci_hcd and address 2
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
Loading ehci-hcd.ko module
GSI 23 (level, low) -> CPU 0 (0x0000) vector 51
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 51
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 51, io mem 0xf7fffc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
Loading jbd.ko module
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_sas.ko module
Loading mptbase.ko module
Fusion MPT base driver 3.04.04
Copyright (c) 1999-2007 LSI Logic Corporation
Loading mptscsih.ko module
Loading mptsas.ko module
Fusion MPT SAS Host driver 3.04.04
GSI 48 (level, low) -> CPU 0 (0x0000) vector 52
ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 52
mptbase: Initiating ioc0 bringup
usb 2-1: device not accepting address 2, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
input: Unisys Corporation as /class/input/input0
input: USB HID v1.01 Keyboard [Unisys Corporation] on usb-0000:00:1d.1-1
input: Unisys Corporation as /class/input/input1
input: USB HID v1.01 Mouse [Unisys Corporation] on usb-0000:00:1d.1-1
usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input2
input: USB HID v1.00 Keyboard [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-
0000:00:1d.2-1
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input3
input: USB HID v1.00 Mouse [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-000
0:00:1d.2-1
ioc0: SAS1068: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1068, FwRev=010a0000h, Ports=1, MaxQ=511, IRQ=52
scsi 0:0:0:0: Direct-Access     FUJITSU  MAV2073RC        0109 PQ: 0 ANSI: 3
sd 0:0:0:0: [sda] 140625000 512-byte hardware sectors (72000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: bf 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
 or FUA
sd 0:0:0:0: [sda] 140625000 512-byte hardware sectors (72000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: bf 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
 or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Waiting for driver initialization.
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1183991194.200:2): selinux=0 auid=4294967295
INIT: version 2.86 booting
		Welcome to Red Hat Enterprise Linux Server
		Press 'I' to enter interactive startup.
Setting clock  (utc): Mon Jul  9 10:26:38 EDT 2007 [  OK  ]
Starting udev: [  OK  ]
Loading default keymap (us): [  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Setting up Logical Volume Management:   /dev/hda: open failed: No medium found
  2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 194240/17039360 files, 2813726/17039360 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting background readahead: [  OK  ]
Checking for hardware changes [  OK  ]
Loading uscd driver...
Rebuilding USCD module: [FAILED]
Starting uscm services.../sys/devices/system/uscd/uscd0/hmbox: No such file or d
irectory
Couldn't read /sys/devices/system/uscd/uscd0/hmbox, rv: -2
[FAILED]
Starting uscr services...[  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
[  OK  ]
Bringing up interface eth1:  
Determining IP information for eth1... failed; no link present.  Check cable?
[FAILED]
Starting auditd: [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting portmap: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: [  OK  ]
No kdump initial ramdisk found.[WARNING]
Rebuilding /boot/efi/efi/redhat/initrd-2.6.22benkdump.img
Starting kdump:[FAILED]
Starting system message bus: [  OK  ]
Starting Bluetooth services:[  OK  ][  OK  ]
Mounting other filesystems:  [  OK  ]
Starting PC/SC smart card daemon (pcscd): [  OK  ]
Starting hidd: [  OK  ]
Starting autofs:  Loading autofs4: [  OK  ]
Starting automount: [  OK  ]
[  OK  ]
Starting acpi daemon: [  OK  ]
Starting hpiod: [  OK  ]
Starting hpssd: [  OK  ]
Starting cups: [  OK  ]
Starting sshd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting console mouse services: [  OK  ]
Starting crond: [  OK  ]
Starting xfs: [  OK  ]
Starting anacron: [  OK  ]
Starting atd: [  OK  ]
Starting salinfo_decode_all: [  OK  ]
Starting yum-updatesd: [  OK  ]
Starting Avahi daemon... [  OK  ]
Starting HAL daemon: [  OK  ]
Starting smartd: [  OK  ]

Red Hat Enterprise Linux Server release 5 (Tikanga)
Kernel 2.6.22ben on an ia64

localhost.localdomain login: root
Password: 
Last login: Mon Jul  9 10:27:40 on tty1
[root at localhost ~]# cat /proc/iomem
00000000-00000fff : System RAM
00001000-00089fff : System RAM
0008a000-0009ffff : System RAM
000a0000-000fffff : PCI Bus 0000:00
  000c0000-000fffff : reserved
00100000-03ffffff : System RAM
04000000-04ee3fff : System RAM
  04000000-0463bcbf : Kernel code
  0463bcc0-04ee352f : Kernel data
04ee4000-37dfffff : System RAM
37e00000-37efffff : reserved
37f00000-efffffff : System RAM
f2000000-f3ffffff : PCI Bus 0000:09
  f2e00000-f2ffffff : PCI Bus #0d
    f2effc00-f2effcff : 0000:0d:1f.0
  f3e00000-f3efffff : PCI Bus #0d
  f3f00000-f3ffffff : PCI Bus #0a
    f3fc0000-f3fdffff : 0000:0a:01.1
      f3fc0000-f3fdffff : e1000
    f3fe0000-f3ffffff : 0000:0a:01.0
      f3fe0000-f3ffffff : e1000
f4000000-f4ffffff : PCI Bus 0000:02
  f4f00000-f4ffffff : PCI Bus #06
    f4fec000-f4feffff : 0000:06:01.0
    f4ff0000-f4ffffff : 0000:06:01.0
f5000000-f7ffffff : PCI Bus 0000:00
  f6000000-f7efffff : PCI Bus #01
    f6000000-f6ffffff : 0000:01:01.0
    f7ef8000-f7efbfff : 0000:01:02.0
    f7efc000-f7efcfff : 0000:01:03.0
    f7efd000-f7efdfff : 0000:01:03.0
    f7efe800-f7efefff : 0000:01:02.0
    f7eff000-f7efffff : 0000:01:01.0
  f7fffc00-f7ffffff : 0000:00:1d.7
    f7fffc00-f7ffffff : ehci_hcd
f8000000-fc72bfff : System RAM
fc72c000-fcc65fff : reserved
fcc66000-fcca5fff : reserved
fcca6000-fcffffff : reserved
fd000000-fd2fffff : reserved
fd300000-fdec8fff : System RAM
fdec9000-fdedffff : System RAM
fdee0000-fdee7fff : reserved
fdee8000-fdeedfff : System RAM
fdeee000-fdffffff : reserved
fec02000-fec02fff : 0000:02:1c.0
fec03000-fec03fff : 0000:02:1e.0
fec04000-fec04fff : 0000:09:1c.0
fec05000-fec05fff : 0000:09:1e.0
ff000000-ff01ffff : reserved
ff42a000-ff469fff : reserved
ff800000-ffffffff : reserved
100000000-1006bdbfff : System RAM
1006bdc000-1006be1fff : System RAM
  1006bdc010-1006bdc060 : Boot parameter
1006be2000-1006be2fff : System RAM
1006be3000-1006f9ffff : System RAM
  1006f9c010-1006f9c970 : EFI Memory Map
1006fa0000-1006fa0fff : System RAM
1006fa1000-1006ffdfff : System RAM
1006ffe000-1007152fff : System RAM
1007153000-1007800fff : System RAM
1007801000-1007919fff : System RAM
100791a000-100791bfff : System RAM
100791c000-100791dfff : System RAM
100791e000-1007923fff : System RAM
1007924000-1007925fff : System RAM
1007926000-10079f9fff : System RAM
10079fa000-10079fafff : System RAM
10079fb000-10079fdfff : System RAM
10079fe000-1007cfbfff : System RAM
1007cfc000-1007d65fff : reserved
1007d66000-1007dcffff : System RAM
1007dd0000-1007dfdfff : System RAM
1007dfe000-1007e29fff : System RAM
1007e2a000-1007e2bfff : reserved
1007e2c000-1007e2dfff : System RAM
1007e2e000-1007e7dfff : reserved
1007e7e000-1007fb5fff : System RAM
1007fb6000-1007ffffff : reserved
ffffc000000-ffffc7fffff : PCI Bus 0000:00 I/O Ports 00000000-00001fff
ffffc800000-ffffc9ff7ff : PCI Bus 0000:02 I/O Ports 00002000-000027ff
ffffca00800-fffffffffff : PCI Bus 0000:09 I/O Ports 00002800-0000ffff
[root at localhost ~]# ca  cat benkexec
#!/bin/bash
echo 15 > /proc/sys/kernel/printk
kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.22ben --append="root=/dev/VolGroup00/L
ogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic=debug 3 ro" 
--initrd=/boot/efi/efi/redhat/initrd-2.6.22ben 
[root at localhost ~]# ,.  ./benkexec 
Cannot open `/boot/efi/efi/redhat/initrd-2.6.22ben': No such file or directory
[root at localhost ~]# ./benkexec cat benkexec
#!/bin/bash
echo 15 > /proc/sys/kernel/printk
kexec -l /boot/efi/efi/redhat/vmlinuz-2.6.22ben --append="root=/dev/VolGroup00/L
ogVol00 rhgb console=uart,io,0x3f8,115200n8 console=tty0 debug apic=debug 3 ro" 
--initrd=/boot/efi/efi/redhat/initrd-2.6.22ben.img
[root at localhost ~]# cat benkexec./benkexec  
[root at localhost ~]# kexec -e
md: stopping all md devices.
sd 0:0:0:0: [sda] Synchronizing SCSI cache
ACPI: PCI interrupt for device 0000:0a:01.1 disabled
GSI 73 (level, low) -> CPU 0 (0x0000) vector 54 unregistered
ACPI: PCI interrupt for device 0000:0a:01.0 disabled
GSI 72 (level, low) -> CPU 0 (0x0000) vector 53 unregistered
Starting new kernel
Linux version 2.6.22ben (root at localhost.localdomain) (gcc version 4.1.1 20070105
 (Red Hat 4.1.1-52)) #1 SMP Mon Jul 9 10:15:01 EDT 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP 000F7320, 0024 (r2 PTLTD )
ACPI: XSDT FCB4AA16, 005C (r1 PTLTD  	 XSDT    6040000  LTP        0)
ACPI: FACP FCBA2CB4, 00F4 (r3 UNISYS ZORRO     6040000 PTL     F4240)
ACPI: DSDT FCB4AA72, 58242 (r1  Intel  870 SMP  6040000 MSFT  3000000)
ACPI: FACS FCBA4F00, 0040
ACPI: OEM1 FCBA2DA8, 0030 (r1 UNISYS   OEM1    6040000  LTP        0)
ACPI: SRAT FCBA2DD8, 0090 (r1 UNISYS   SRAT    6040000  LTP        0)
ACPI: IPPT FCBA2E68, 003A (r1 UNISYS   IPPT    6040000  LTP        0)
ACPI: APIC FCBA2EA2, 00E6 (r1 PTLTD  	 APIC    6040000  LTP        0)
ACPI: BOOT FCBA2F88, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
ACPI: SPCR FCBA2FB0, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
Number of logical nodes in system = 1
Number of memory chunks in system = 2
Initial ramdisk at: 0xe000001007948000 (3870554 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
Zone PFN ranges:
  DMA          1024 ->   262144
  Normal     262144 ->  4202496
early_node_map[8] active PFN ranges
    0:     1024 ->    57216
    0:    57280 ->   245760
    0:   253952 ->   258507
    0:   259264 ->   260024
    0:   260026 ->   260027
    0:   262144 ->  4202303
    0:  4202330 ->  4202378
    0:  4202400 ->  4202477
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4175913
Kernel command line: root=/dev/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,11
5200n8 console=tty0 debug apic=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Linux version 2.6.22ben (root at localhost.localdomain) (gcc version 4.1.1 20070105
 (Red Hat 4.1.1-52)) #1 SMP Mon Jul 9 10:15:01 EDT 2007
EFI v1.10 by INTEL: SALsystab=0xfcb49560 ACPI=0xfcbd2008 ACPI 2.0=0xf7320 MPS=0x
fcba5f00 SMBIOS=0xf74a0
booting generic kernel on platform dig
Early serial console at I/O port 0x3f8 (options '115200n8')
ACPI: RSDP 000F7320, 0024 (r2 PTLTD )
ACPI: XSDT FCB4AA16, 005C (r1 PTLTD  	 XSDT    6040000  LTP        0)
ACPI: FACP FCBA2CB4, 00F4 (r3 UNISYS ZORRO     6040000 PTL     F4240)
ACPI: DSDT FCB4AA72, 58242 (r1  Intel  870 SMP  6040000 MSFT  3000000)
ACPI: FACS FCBA4F00, 0040
ACPI: OEM1 FCBA2DA8, 0030 (r1 UNISYS   OEM1    6040000  LTP        0)
ACPI: SRAT FCBA2DD8, 0090 (r1 UNISYS   SRAT    6040000  LTP        0)
ACPI: IPPT FCBA2E68, 003A (r1 UNISYS   IPPT    6040000  LTP        0)
ACPI: APIC FCBA2EA2, 00E6 (r1 PTLTD  	 APIC    6040000  LTP        0)
ACPI: BOOT FCBA2F88, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
ACPI: SPCR FCBA2FB0, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
Number of logical nodes in system = 1
Number of memory chunks in system = 2
Entering add_active_range(0, 1024, 57216) 0 entries of 51200 used
Entering add_active_range(0, 57280, 245760) 1 entries of 51200 used
Entering add_active_range(0, 253952, 258507) 2 entries of 51200 used
Entering add_active_range(0, 259264, 260024) 3 entries of 51200 used
Entering add_active_range(0, 260026, 260027) 4 entries of 51200 used
Entering add_active_range(0, 262144, 4202303) 5 entries of 51200 used
Entering add_active_range(0, 4202330, 4202378) 6 entries of 51200 used
Entering add_active_range(0, 4202400, 4202477) 7 entries of 51200 used
Initial ramdisk at: 0xe000001007948000 (3870554 bytes)
SAL 3.0: Phoenix Technologies SAL Product ID version 0.60
SAL Platform features:
SAL: AP wakeup using external interrupt vector 0xbf
cpu package is Multi-Core capable: number of cores=2
cpu package is Multi-Threading capable: number of siblings=2
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
1 CPUs available, 1 CPUs total
MCA related initialization done
Zone PFN ranges:
  DMA          1024 ->   262144
  Normal     262144 ->  4202496
early_node_map[8] active PFN ranges
    0:     1024 ->    57216
    0:    57280 ->   245760
    0:   253952 ->   258507
    0:   259264 ->   260024
    0:   260026 ->   260027
    0:   262144 ->  4202303
    0:  4202330 ->  4202378
    0:  4202400 ->  4202477
On node 0 totalpages: 4190272
  DMA zone: 892 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 249096 pages, LIFO batch:7
  Normal zone: 13467 pages used for memmap
  Normal zone: 3926817 pages, LIFO batch:7
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 4175913
Kernel command line: root=/dev/VolGroup00/LogVol00 rhgb console=uart,io,0x3f8,11
5200n8 console=tty0 debug apic=debug 3 ro
PID hash table entries: 4096 (order: 12, 32768 bytes)
CPU 0: base freq=200.025MHz, ITC ratio=8/4, ITC freq=400.050MHz
Console: colour VGA+ 80x25
Placing software IO TLB between 0x8f98000 - 0xcf98000
Memory: 66594208k/67025248k available (6383k code, 450144k reserved, 4234k data,
 672k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 3194.88 BogoMIPS (lpj=1597440)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Dentry cache hash table entries: 8388608 (order: 12, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 11, 33554432 bytes)
Mount-cache hash table entries: 1024
ACPI: Core revision 20070126
Boot processor id 0x0/0x0
Brought up 1 CPUs
Total of 1 processors activated (3194.88 BogoMIPS).
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: Device [MBDV] status [00000008]: functional but not present; setting prese
nt
ACPI: Device [MEDV] status [00000008]: functional but not present; setting prese
nt
ACPI: PCI Root Bridge [MBDV] (0000:ff)
ACPI: PCI Root Bridge [MEDV] (0000:fe)
ACPI: PCI Root Bridge [S0H0] (0000:00)
PCI quirk: region 0d00-0d7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0d80-0dbf claimed by ICH4 GPIO
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H0.PCI1._PRT]
ACPI: PCI Root Bridge [S0H1] (0000:02)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H1.PCI1._PRT]
ACPI: PCI Root Bridge [S0H2] (0000:09)
PCI: Enable I/O Space to 1 KB Granularity
PCI: Enable I/O Space to 1 KB Granularity
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.S0H2.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 6 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 9 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 8388608 (order: 13, 201326592 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 8388608 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3776kB freed
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
audit: initializing netlink socket (disabled)
audit(1183991371.661:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 16384 bytes)
SELinux:  Registering netfilter hooks
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not pres
ent [20070126]
EFI Time Services Driver v0.4
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled
00:06: ttyS0 at I/O 0x3f8 (irq = 44) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Device 0000:00:1f.1 not available because of resource collisions
GSI 18 (level, low) -> CPU 0 (0x0000) vector 48
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 48
ICH4: BIOS configuration fixed.
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x0880-0x0887, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x0888-0x088f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-6750A, ATAPI CD/DVD-ROM drive
hda: selected mode 0x42
ide0 at 0x1f0-0x1f7,0x3f6 on irq 34
Probing IDE interface ide1...
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
EFI Variables Facility v0.08 2004-May-17
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Adding console on ttyS0 at I/O port 0x3f8 (options '115200n8')
Freeing unused kernel memory: 672kB freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
GSI 16 (level, low) -> CPU 0 (0x0000) vector 49
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 49
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 49, io base 0x00000800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
GSI 19 (level, low) -> CPU 0 (0x0000) vector 50
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 50
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 50, io base 0x00000820
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 48
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 48, io base 0x00000840
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Loading ohci-hcd.ko module
usb 2-1: new full speed USB device using uhci_hcd and address 2
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
Loading ehci-hcd.ko module
GSI 23 (level, low) -> CPU 0 (0x0000) vector 51
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 51
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 51, io mem 0xf7fffc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
Loading jbd.ko module
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_sas.ko module
Loading mptbase.ko module
Fusion MPT base driver 3.04.04
Copyright (c) 1999-2007 LSI Logic Corporation
Loading mptscsih.ko module
Loading mptsas.ko module
Fusion MPT SAS Host driver 3.04.04
PCI: Enabling device 0000:06:01.0 (0156 -> 0157)
GSI 48 (level, low) -> CPU 0 (0x0000) vector 52
ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 52
mptbase: Initiating ioc0 bringup
usb 2-1: device not accepting address 2, error -71
usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
input: Unisys Corporation as /class/input/input0
input: USB HID v1.01 Keyboard [Unisys Corporation] on usb-0000:00:1d.1-1
input: Unisys Corporation as /class/input/input1
input: USB HID v1.01 Mouse [Unisys Corporation] on usb-0000:00:1d.1-1
usb 3-1: new low speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input2
input: USB HID v1.00 Keyboard [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-
0000:00:1d.2-1
input: Cypress Cypress USB Keyboard / PS2 Mouse as /class/input/input3
input: USB HID v1.00 Mouse [Cypress Cypress USB Keyboard / PS2 Mouse] on usb-000
0:00:1d.2-1
ioc0: SAS1068: Capabilities={Initiator}
scsi0 : ioc0: LSISAS1068, FwRev=010a0000h, Ports=1, MaxQ=511, IRQ=52
scsi 0:0:0:0: Direct-Access     FUJITSU  MAV2073RC        0109 PQ: 0 ANSI: 3
sd 0:0:0:0: [sda] 140625000 512-byte hardware sectors (72000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: bf 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
 or FUA
sd 0:0:0:0: [sda] 140625000 512-byte hardware sectors (72000 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: bf 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
 or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Waiting for driver initialization.
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1183991412.080:2): selinux=0 auid=4294967295
INIT: version 2.86 booting
		Welcome to Red Hat Enterprise Linux Server
		Press 'I' to enter interactive startup.
Setting clock  (utc): Mon Jul  9 10:30:16 EDT 2007 [  OK  ]
Starting udev: [  OK  ]
Loading default keymap (us): [  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Setting up Logical Volume Management:   /dev/hda: open failed: No medium found
  2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 194302/17039360 files, 2813817/17039360 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting background readahead: [  OK  ]
Checking for hardware changes [  OK  ]
Loading uscd driver...
Rebuilding USCD module: [FAILED]
Starting uscm services.../sys/devices/system/uscd/uscd0/hmbox: No such file or d
irectory
Couldn't read /sys/devices/system/uscd/uscd0/hmbox, rv: -2
[FAILED]
Starting uscr services...[  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
[  OK  ]
Bringing up interface eth1:  
Determining IP information for eth1... failed; no link present.  Check cable?
[FAILED]
Starting auditd: [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting portmap: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: [  OK  ]
Starting kdump:[FAILED]
Starting system message bus: [  OK  ]
Starting Bluetooth services:[  OK  ][  OK  ]
Mounting other filesystems:  [  OK  ]
Starting PC/SC smart card daemon (pcscd): [  OK  ]
Starting hidd: [  OK  ]
Starting autofs:  Loading autofs4: [  OK  ]
Starting automount: [  OK  ]
[  OK  ]
Starting acpi daemon: [  OK  ]
Starting hpiod: [  OK  ]
Starting hpssd: [  OK  ]
Starting cups: [  OK  ]
Starting sshd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting console mouse services: [  OK  ]
Starting crond: [  OK  ]
Starting xfs: [  OK  ]
Starting anacron: [  OK  ]
Starting atd: [  OK  ]
Starting salinfo_decode_all: [  OK  ]
Starting yum-updatesd: [  OK  ]
Starting Avahi daemon... [  OK  ]
Starting HAL daemon: [  OK  ]
Starting smartd: [  OK  ]

Red Hat Enterprise Linux Server release 5 (Tikanga)
Kernel 2.6.22ben on an ia64

localhost.localdomain login: root
Password: 
Last login: Mon Jul  9 10:28:28 on ttyS0
[root at localhost ~]# cat /proc/iomem
00000000-00000fff : System RAM
00001000-00089fff : System RAM
0008a000-0009ffff : System RAM
000a0000-000fffff : PCI Bus 0000:00
  000c0000-000fffff : reserved
00100000-03ffffff : System RAM
04000000-048cffff : System RAM
  04000000-0463bcbf : Kernel code
048d0000-048dffff : System RAM
048e0000-04eeffff : System RAM
04ef0000-37dfffff : System RAM
37e00000-37efffff : reserved
37f00000-efffffff : System RAM
f2000000-f3ffffff : PCI Bus 0000:09
  f2e00000-f2ffffff : PCI Bus #0d
    f2effc00-f2effcff : 0000:0d:1f.0
  f3e00000-f3efffff : PCI Bus #0d
  f3f00000-f3ffffff : PCI Bus #0a
    f3fc0000-f3fdffff : 0000:0a:01.1
      f3fc0000-f3fdffff : e1000
    f3fe0000-f3ffffff : 0000:0a:01.0
      f3fe0000-f3ffffff : e1000
f4000000-f4ffffff : PCI Bus 0000:02
  f4f00000-f4ffffff : PCI Bus #06
    f4fec000-f4feffff : 0000:06:01.0
    f4ff0000-f4ffffff : 0000:06:01.0
f5000000-f7ffffff : PCI Bus 0000:00
  f6000000-f7efffff : PCI Bus #01
    f6000000-f6ffffff : 0000:01:01.0
    f7ef8000-f7efbfff : 0000:01:02.0
    f7efc000-f7efcfff : 0000:01:03.0
    f7efd000-f7efdfff : 0000:01:03.0
    f7efe800-f7efefff : 0000:01:02.0
    f7eff000-f7efffff : 0000:01:01.0
  f7fffc00-f7ffffff : 0000:00:1d.7
    f7fffc00-f7ffffff : ehci_hcd
f8000000-fc72bfff : System RAM
fc72c000-fcc65fff : reserved
fcc66000-fcca5fff : reserved
fcca6000-fcffffff : reserved
fd000000-fd2fffff : reserved
fd300000-fdec8fff : System RAM
fdec9000-fdedffff : System RAM
fdee0000-fdee7fff : reserved
fdee8000-fdeedfff : System RAM
fdeee000-fdffffff : reserved
fec02000-fec02fff : 0000:02:1c.0
fec03000-fec03fff : 0000:02:1e.0
fec04000-fec04fff : 0000:09:1c.0
fec05000-fec05fff : 0000:09:1e.0
ff000000-ff01ffff : reserved
ff42a000-ff469fff : reserved
ff800000-ffffffff : reserved
100000000-1006bdbfff : System RAM
1006bdc000-1006be1fff : System RAM
1006be2000-1006be2fff : System RAM
1006be3000-1006f9ffff : System RAM
1006fa0000-1006fa0fff : System RAM
1006fa1000-1006ffdfff : System RAM
1006ffe000-1007152fff : System RAM
1007153000-1007800fff : System RAM
1007801000-1007919fff : System RAM
100791a000-100791bfff : System RAM
100791c000-100791dfff : System RAM
100791e000-1007923fff : System RAM
1007924000-1007925fff : System RAM
1007926000-10079f9fff : System RAM
10079fa000-10079fafff : System RAM
10079fb000-10079fdfff : System RAM
10079fe000-1007cfbfff : System RAM
1007cfc000-1007d65fff : reserved
1007d66000-1007dcffff : System RAM
1007dd0000-1007dfdfff : System RAM
1007dfe000-1007e29fff : System RAM
1007e2a000-1007e2bfff : reserved
1007e2c000-1007e2dfff : System RAM
1007e2e000-1007e7dfff : reserved
1007e7e000-1007fb5fff : System RAM
  1007f88000-1007f889c0 : EFI Memory Map
  1007f90000-1007f90050 : Boot parameter
1007fb6000-1007ffffff : reserved
ffffc000000-ffffc7fffff : PCI Bus 0000:00 I/O Ports 00000000-00001fff
ffffc800000-ffffc9ff7ff : PCI Bus 0000:02 I/O Ports 00002000-000027ff
ffffca00800-fffffffffff : PCI Bus 0000:09 I/O Ports 00002800-0000ffff
[root at localhost ~]# shutdown          init 0
[root at localhost Shutting down smartd: [  OK  ]
Shutting down Avahi daemon: [  OK  ]
Stopping HAL daemon: [  OK  ]
Stopping yum-updatesd: [  OK  ]
Stopping anacron: [  OK  ]
Stopping atd: [  OK  ]
Stopping cups: [  OK  ]
Stopping hpiod: [  OK  ]
Stopping hpssd: [  OK  ]
Shutting down xfs: [  OK  ]
Shutting down console mouse services: [  OK  ]
Stopping sshd: [  OK  ]
Shutting down sm-client: [  OK  ]
Shutting down sendmail: [  OK  ]
Stopping acpi daemon: [  OK  ]
Stopping crond: [  OK  ]
Shutting down RPC idmapd: [  OK  ]
Stopping autofs:  Stopping automount: [  OK  ]
[  OK  ]
Stopping system message bus: [  OK  ]
Stopping NFS statd: [  OK  ]
Stopping portmap: [  OK  ]
Stopping auditd: audit(1183991776.391:14): audit_pid=0 old=2849 by auid=42949672
95
[  OK  ]
Stopping PC/SC smart card daemon (pcscd): [  OK  ]
Shutting down kernel logger: [  OK  ]
Shutting down system logger: [  OK  ]
Shutting down hidd: [  OK  ]
Stopping Bluetooth services:[  OK  ][  OK  ]
Shutting down interface eth0:  [  OK  ]
Shutting down loopback interface:  [  OK  ]
IPv6 over IPv4 tunneling driver
sit0: Disabled Privacy Extensions
Starting killall:  [  OK  ]
Sending all processes the TERM signal... 
Sending all processes the KILL signal... 
Saving random seed:  
Syncing hardware clock to system time audit(1183991785.999:15): user pid=4304 ui
d=0 auid=4294967295 msg='changing system time: exe="/sbin/hwclock" (hostname=?, 
addr=?, terminal=console res=success)'

Turning off swap:  
Turning off quotas:  
Unmounting pipe file systems:  
Unmounting file systems:  
Halting system...
md: stopping all md devices.
sd 0:0:0:0: [sda] Synchronizing SCSI cache
ACPI: PCI interrupt for device 0000:0a:01.1 disabled
GSI 73 (level, low) -> CPU 0 (0x0000) vector 54 unregistered
ACPI: PCI interrupt for device 0000:0a:01.0 disabled
GSI 72 (level, low) -> CPU 0 (0x0000) vector 53 unregistered
Power down.
acpi_power_off called

From da-x at monatomic.org  Tue Jul 10 04:14:14 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 11:14:14 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710064817.GC5471@in.ibm.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
Message-ID: <20070710081413.GA29034@localdomain>

On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > 
>[..]
> > It contains enough information in order to make a compact kernel
> > dump (makedumpinfo needs to go over the struct page arrays). As
> > you see, it also contains the kernel version.
> > 
> 
> But this will not solve Bernhard's problem where looking at a vmcore
> he wants to know which vmlinux (kernel version with time stamp) has
> generated this vmcore. So adding a ELF NOTE should help.

That, or pass it in *runtime* by other means.
 
> > However, this file needs to be passed somehow to the rootfs
> > of the kdump kernel. This poses a chicken-and-egg problem on 
> > my setup where the initramfs of the first kernel contains 
> > a staticlu linked version of the kexec executable along with a
> > kdump kernel to be loaded before mount rootfs and running 
> > init. 
> > 
> 
> Why are you loading kdump kernel from first kernel's initramfs?
> I guess to enable the dump capture as soon as possible so if some
> driver panics() you can capture the dump?

Yes, that's one of the reasons.
 
> Can't we modify the initramfs generation process (mkinitrd) to take
> care of this situation?. By the way, how is second kernel's initramfs
> is generated currently? The moment we start packing a file which contains
> the debuginfo for first kernel, initramfs of second kernel becomes dependent
> on first kernel and to me its not a good approach.

That's not what I'm aiming for, they are actually independent (my 
initramfs is a build-time constant). I have described it in another
mail.
 
> A dump kernel and its initrd should be independent of the crashing kernel.

I agree.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From bwalle at suse.de  Tue Jul 10 04:23:16 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 10 Jul 2007 10:23:16 +0200
Subject: [PATCH] Determine ELF32/ELF64 automatically on i386
In-Reply-To: <20070710055259.GA5471@in.ibm.com>
References: <20070702131541.GA6084@suse.de> <20070703161207.GA5070@suse.de>
	<20070710055259.GA5471@in.ibm.com>
Message-ID: <20070710082316.GA17090@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-10 07:52]:
> On Tue, Jul 03, 2007 at 06:12:07PM +0200, Bernhard Walle wrote:
> > 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.
> > 
> 
> Makes sense to me. No need to generate 64bit ELF headers on systems
> having less than 4G of memory. gdb runs into issues with 64bit ELF headers
> on 32bit machines.

Exaclty that was my point.

> I think we can avoid mixed case in "CoreType" and use something like
> "coretype".

Of course:

----

[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 at suse.de>

---
 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
@@ -486,6 +486,23 @@ 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 */
+		if (ranges == 0)
+			return CORE_TYPE_ELF64;
+
+		if (range[ranges].end > 0xFFFFFFFFUL)
+			return CORE_TYPE_ELF64;
+		else
+			return CORE_TYPE_ELF32;
+	}
+}
+
 /* Loads additional segments in case of a panic kernel is being loaded.
  * One segment for backup region, another segment for storing elf headers
  * for crash memory image.
@@ -501,6 +518,15 @@ int load_crashdump_segments(struct kexec
 	if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
 		return -1;
 
+	/*
+	 * if the core type has not been set on command line, set it here
+	 * automatically
+	 */
+	if (arch_options.core_header_type == CORE_TYPE_UNDEF) {
+		arch_options.core_header_type =
+			get_core_type(info, mem_range, nr_ranges);
+	}
+
 	/* Memory regions which panic kernel can safely use to boot into */
 	sz = (sizeof(struct memory_range) * (KEXEC_MAX_SEGMENTS + 1));
 	memmap_p = xmalloc(sz);
--- a/kexec/arch/i386/kexec-x86.c
+++ b/kexec/arch/i386/kexec-x86.c
@@ -145,7 +145,7 @@ struct arch_options_t arch_options = {
 	.serial_baud = 0,
 	.console_vga = 0,
 	.console_serial = 0,
-	.core_header_type = CORE_TYPE_ELF64,
+	.core_header_type = CORE_TYPE_UNDEF,
 };
 
 int arch_process_options(int argc, char **argv)
--- a/kexec/arch/i386/kexec-x86.h
+++ b/kexec/arch/i386/kexec-x86.h
@@ -2,8 +2,12 @@
 #define KEXEC_X86_H
 
 #define MAX_MEMORY_RANGES 64
-#define CORE_TYPE_ELF32 1
-#define CORE_TYPE_ELF64 2
+
+enum coretype {
+	CORE_TYPE_UNDEF = 0,
+	CORE_TYPE_ELF32 = 1,
+	CORE_TYPE_ELF64 = 2
+};
 
 extern unsigned char compat_x86_64[];
 extern uint32_t compat_x86_64_size, compat_x86_64_entry32;
@@ -40,12 +44,12 @@ struct entry16_regs {
 };
 
 struct arch_options_t {
-	uint8_t  reset_vga;
-	uint16_t serial_base;
-	uint32_t serial_baud;
-	uint8_t  console_vga;
-	uint8_t  console_serial;
-	int	 core_header_type;
+	uint8_t  	reset_vga;
+	uint16_t 	serial_base;
+	uint32_t 	serial_baud;
+	uint8_t  	console_vga;
+	uint8_t  	console_serial;
+	enum coretype	core_header_type;
 };
 
 int multiboot_x86_probe(const char *buf, off_t len);


From nhorman at redhat.com  Tue Jul 10 08:02:43 2007
From: nhorman at redhat.com (Neil Horman)
Date: Tue, 10 Jul 2007 08:02:43 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710121315oomichi@mail.jp.nec.com>
References: <20070706132814.GA7079@suse.de>
	<20070710121315oomichi@mail.jp.nec.com>
Message-ID: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 12:13:15PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni <da-x at monatomic.org> wrote:
> > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > Hello,
> > > 
> > > does anybody know a _reliable_ way to determine the version the kernel
> > > that produced a vmcore file? This means not scanning for a specific
> > > string or something like that which can fail on random memory.
> > > 
> > > Would it make sense to add a ELF PT_NOTE section in the vmcore?
> > > 
> > > Thanks for input!
> 
> (CONFIGFILE means makedumpfile's config file.)
> 
> makedumpfile checks kernel version by reading system_utsname.release
> from /proc/vmcore, as you know. If the release and OSRELEASE in CONFIGFILE
> don't match, makedumpfile fails.
> 
> Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
> In the kernel building process, distributors need to make CONFIGFILE
> on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
> may be an older kernel. So OSRELEASE should be modified to the building
> kernel version by hand, but it is not smart.
> 
> To solve this problem, I'm proposing 2 plans.
> Could you give me your opinion ?
> 
> Plan 1:
>   A new option [--osrelease="string"] is added.
>   The OSRELEASE of CONFIGFILE is overwritten by "string".
>   In the kernel building process, distributors should specify "string"
>   as the building kernel version.
> 
> Plan2:
>   Remove the OSRELEASE from CONFIGFILE.
>   Instead of checking the OSRELEASE, makedumpfile only checks whether the
>   area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
>   is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
>   "system_utsname" must not point to the correct area in most cases.
>   Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
>   But I think there are not any problems because old makedumpfile will not
>   read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
>   the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
>   will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
>   should be updated with CONFIGFILE.
> 
> 
> I'd like to change the name of CONFIGFILE to mkdfinfo.
> 
Why not, instead of either plan above, just redefine OSRELEASE to be the version
of the kernel the config file was built against?  i.e. when you build a config
file, you need to specify a kernel to extract symbol information from, why not
grab the utsname from that kernel and use that to set OSRELEASE?  When you're
building a config file the running kernel on the system isn't really relevent
anyway.

Thanks & Regards
Neil

> 
> Thanks
> Ken'ichi Ohmichi

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From nhorman at redhat.com  Tue Jul 10 08:09:04 2007
From: nhorman at redhat.com (Neil Horman)
Date: Tue, 10 Jul 2007 08:09:04 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710064817.GC5471@in.ibm.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
Message-ID: <20070710120904.GB10121@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > Hello,
> > > 
> > > does anybody know a _reliable_ way to determine the version the kernel
> > > that produced a vmcore file? This means not scanning for a specific
> > > string or something like that which can fail on random memory.
> > > 
> > > Would it make sense to add a ELF PT_NOTE section in the vmcore?
> > > 
> > > Thanks for input!
> > 
> > (I'm sorry if this E-Mail needlessly turned into a long RFC 
> > but I had to bring this up when I bumped into this question on 
> > LKML)
> > 
> > Actually, instead of another ELF PT_NOTE section for this 
> > information and other things, kdump is currently going into 
> > another direction, described below.
> > 
> > Redhat has a makedumpinfo util which they intend to use as slim
> > kernel-version-independent utility on kdump rootfs in order to
> > save /proc/vmcore in a compact manner.
> > 
> > Normally makedumpinfo would require access to the vmlinux file 
> > that the crashed kernel was originated from. However instead of 
> > depending on vmlinux, it is possible to generate a small textual
> > "CONFIGFILE" that looks like this, for example (generated using
> > makedumpinfo -g):
> > 
> > OSRELEASE=2.6.20.3
> > PAGESIZE=4096
> > SYMBOL(mem_map)=ffffffff806cf5d8
> > SYMBOL(init_uts_ns)=ffffffff805f8be0
> > SYMBOL(_stext)=ffffffff80200f20
> > SYMBOL(node_online_map)=ffffffff80651bc0
> > SYMBOL(contig_page_data)=ffffffff80600e80
> > SIZE(page)=56
> > SIZE(pglist_data)=3712
> > SIZE(zone)=1152
> > SIZE(free_area)=24
> > SIZE(list_head)=16
> > OFFSET(page.flags)=0
> > OFFSET(page._count)=8
> > OFFSET(page.mapping)=24
> > OFFSET(page.lru)=40
> > OFFSET(pglist_data.node_zones)=0
> > OFFSET(pglist_data.nr_zones)=3576
> > OFFSET(pglist_data.node_mem_map)=3584
> > OFFSET(pglist_data.node_start_pfn)=3600
> > OFFSET(pglist_data.node_spanned_pages)=3616
> > OFFSET(zone.free_pages)=0
> > OFFSET(zone.free_area)=408
> > OFFSET(zone.vm_stat)=872
> > OFFSET(zone.spanned_pages)=1064
> > OFFSET(free_area.free_list)=0
> > OFFSET(list_head.next)=0
> > OFFSET(list_head.prev)=8
> > LENGTH(zone.free_area)=11
> > SRCFILE(pud_t)=include/asm/page.h
> > 
> > It contains enough information in order to make a compact kernel
> > dump (makedumpinfo needs to go over the struct page arrays). As
> > you see, it also contains the kernel version.
> > 
> 
> But this will not solve Bernhard's problem where looking at a vmcore
> he wants to know which vmlinux (kernel version with time stamp) has
> generated this vmcore. So adding a ELF NOTE should help.
> 
I think an ELF note would be a fine idea.

> > However, this file needs to be passed somehow to the rootfs
> > of the kdump kernel. This poses a chicken-and-egg problem on 
> > my setup where the initramfs of the first kernel contains 
> > a staticlu linked version of the kexec executable along with a
> > kdump kernel to be loaded before mount rootfs and running 
> > init. 
> > 
> 
> Why are you loading kdump kernel from first kernel's initramfs?
> I guess to enable the dump capture as soon as possible so if some
> driver panics() you can capture the dump?
> 
> Can't we modify the initramfs generation process (mkinitrd) to take
> care of this situation?. By the way, how is second kernel's initramfs
> is generated currently? The moment we start packing a file which contains
We use a modified version of mkinitrd, called mkdumprd to generate the kdump
initramfs.

> the debuginfo for first kernel, initramfs of second kernel becomes dependent
> on first kernel and to me its not a good approach.
> 
> A dump kernel and its initrd should be independent of the crashing kernel.
> 
They are, even if you manually pack them into the first kernels initramfs.  Not
sure where you see a dependency here.

> Neil/Keni'chi, how is this taken care in current RHEL5 build? Is second
> kernel's initramfs dependent on first kernel if one is doing filtering
> in second kernel from initramfs?
> 
No not at all.  Well, not really.  If you configure kdump to use makedumpfile,
the mkdumprd script runs makedumpfile -g to generate a config file that gets
packed into the kdump initramfs for use during the dump process, which is all
makedumpfile needs to successfully filter the crashing kernel.  So we are
dependent on the first kernel during kdump service startup, since we need to
generate that config file, but after that, we're completely independent.

Thanks
Neil

> Thanks
> Vivek

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From nhorman at redhat.com  Tue Jul 10 08:12:25 2007
From: nhorman at redhat.com (Neil Horman)
Date: Tue, 10 Jul 2007 08:12:25 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710081413.GA29034@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710081413.GA29034@localdomain>
Message-ID: <20070710121225.GC10121@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > 
> >[..]
> > > It contains enough information in order to make a compact kernel
> > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > you see, it also contains the kernel version.
> > > 
> > 
> > But this will not solve Bernhard's problem where looking at a vmcore
> > he wants to know which vmlinux (kernel version with time stamp) has
> > generated this vmcore. So adding a ELF NOTE should help.
> 
> That, or pass it in *runtime* by other means.
Wait a second,  I may have been confused before.  Do you want to know the
version of the crashing kernel when you look at a core in the crash utilty, or
do you want to know it when you are capturing the crash?  If you want the
former, then an ELF NOTE would be perfect.  If you want to know the latter, my
suggestion would be to simply modify mkdumprd to place the name of the crashing
kernel, along with its version directly into the kdump initramfs init script.
We can use makedumpfile or readelf to fish out the utsname and just embed it.
Either approach is rather easy to do I think, the former would require a kernel
modification, while the latter would require some extra scripting.

>  
> > > However, this file needs to be passed somehow to the rootfs
> > > of the kdump kernel. This poses a chicken-and-egg problem on 
> > > my setup where the initramfs of the first kernel contains 
> > > a staticlu linked version of the kexec executable along with a
> > > kdump kernel to be loaded before mount rootfs and running 
> > > init. 
> > > 
> > 
> > Why are you loading kdump kernel from first kernel's initramfs?
> > I guess to enable the dump capture as soon as possible so if some
> > driver panics() you can capture the dump?
> 
> Yes, that's one of the reasons.
>  
> > Can't we modify the initramfs generation process (mkinitrd) to take
> > care of this situation?. By the way, how is second kernel's initramfs
> > is generated currently? The moment we start packing a file which contains
> > the debuginfo for first kernel, initramfs of second kernel becomes dependent
> > on first kernel and to me its not a good approach.
> 
> That's not what I'm aiming for, they are actually independent (my 
> initramfs is a build-time constant). I have described it in another
> mail.
>  
> > A dump kernel and its initrd should be independent of the crashing kernel.
> 
> I agree.
> 
And they are.

Neil

> -- 
> Dan Aloni
> XIV LTD, http://www.xivstorage.com
> da-x (at) monatomic.org, dan (at) xiv.co.il

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From bwalle at suse.de  Tue Jul 10 08:52:46 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 10 Jul 2007 14:52:46 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710121315oomichi@mail.jp.nec.com>
References: <20070706132814.GA7079@suse.de>
	<20070710121315oomichi@mail.jp.nec.com>
Message-ID: <20070710125245.GB22862@suse.de>

Hi,

* Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-10 05:13]:
> Plan 1:
>   A new option [--osrelease="string"] is added.
>   The OSRELEASE of CONFIGFILE is overwritten by "string".
>   In the kernel building process, distributors should specify "string"
>   as the building kernel version.
> 
> Plan2:
>   Remove the OSRELEASE from CONFIGFILE.
>   Instead of checking the OSRELEASE, makedumpfile only checks whether the
>   area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
>   is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
>   "system_utsname" must not point to the correct area in most cases.
>   Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
>   But I think there are not any problems because old makedumpfile will not
>   read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
>   the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
>   will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
>   should be updated with CONFIGFILE.

I would propose a third method. Some information cannot be extracted
from the vmlinux file, even with debugging information. That is
currently the page size.

So why not adding an option to makedumpfile which specifies the
.config of the kernel? If the .config is available, it can extract the
missing information (page size) from the .config and also use the
kernel version from this file.

If no config is available, the current process is right since using
the version of the running kernel ensures to some degree (not 100 %)
that the page size is correct.


Thanks,
   Bernhard


From bwalle at suse.de  Tue Jul 10 08:59:05 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 10 Jul 2007 14:59:05 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710063624.GB5471@in.ibm.com>
References: <20070706132814.GA7079@suse.de> <20070710063624.GB5471@in.ibm.com>
Message-ID: <20070710125904.GC22862@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-10 08:36]:
> > does anybody know a _reliable_ way to determine the version the kernel
> > that produced a vmcore file? This means not scanning for a specific
> > string or something like that which can fail on random memory.
> > 
> > Would it make sense to add a ELF PT_NOTE section in the vmcore?
> 
> To me it makes sense to append an ELF NOTE to vmcore which can uniquely
> associate that vmcore with a particular vmlinux file (Some string
> equivalent to the output of uname -a).

Well, if we embed the CONFIGFILE from makedumpfile in some magic way
we don't need it ... we'll see.

> Interesting thing is that to find version of vmlinux, you will still be
> doing <string | grep "some pattern">. Probably then we should append an
> ELF note to vmlinux file also?

Yes, that was my proposal some time ago, see
http://article.gmane.org/gmane.comp.boot-loaders.fastboot.general/3996
Any comments on that patch are appreciated. :)


Thanks,
   Bernhard


From bwalle at suse.de  Tue Jul 10 09:05:03 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 10 Jul 2007 15:05:03 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710121225.GC10121@hmsendeavour.rdu.redhat.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710081413.GA29034@localdomain>
	<20070710121225.GC10121@hmsendeavour.rdu.redhat.com>
Message-ID: <20070710130503.GD22862@suse.de>

* Neil Horman <nhorman at redhat.com> [2007-07-10 14:12]:
> On Tue, Jul 10, 2007 at 11:14:14AM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > > 
> > >[..]
> > > > It contains enough information in order to make a compact kernel
> > > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > > you see, it also contains the kernel version.
> > > > 
> > > 
> > > But this will not solve Bernhard's problem where looking at a vmcore
> > > he wants to know which vmlinux (kernel version with time stamp) has
> > > generated this vmcore. So adding a ELF NOTE should help.
> > 
> > That, or pass it in *runtime* by other means.
> Wait a second,  I may have been confused before.  Do you want to know the
> version of the crashing kernel when you look at a core in the crash utilty, or
> do you want to know it when you are capturing the crash?  If you want the
> former, then an ELF NOTE would be perfect.  If you want to know the latter, my
> suggestion would be to simply modify mkdumprd to place the name of the crashing
> kernel, along with its version directly into the kdump initramfs init script.
> We can use makedumpfile or readelf to fish out the utsname and just embed it.
> Either approach is rather easy to do I think, the former would require a kernel
> modification, while the latter would require some extra scripting.

Well, mkdumprd is RedHat specific. (We use the normal mkinitrd for
this.) 

Also, I don't want to rebuild the initrd of the kdump kernel just only
after changing the running kernel. That would require to rebuild the
initrd for the kdump kernel on *every* boot of a kernel that's another
version than the last booted kernel.



Thanks,
   Bernhard


From bwalle at suse.de  Tue Jul 10 09:20:31 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 10 Jul 2007 15:20:31 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710044546.GA2240@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070709204938.GA21663@suse.de>
	<20070710044546.GA2240@localdomain>
Message-ID: <20070710132031.GE22862@suse.de>

Hello,

* Dan Aloni <da-x at monatomic.org> [2007-07-10 06:45]:
> > > 
> > > Not exactly. Let me describe the procedure in greater detail.
> > > Basically, it would go like this:
> > > 
> > > 1. <normal bootloader boot>
> > > 2. <normal initramfs>
> > > 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> > > 4. kexec -l vmlinux-kdump <....>
> > > 5. <boot continues>
> > > 6. <crash>
> > > 7. <kdump kernel boot>
> > > 8. <kdump initramfs runs>
> > > 9. makedumpfile -i /proc/vmcore.info <....>
> > 
> > I don't see why an additional tool would be needed here. kexec already
> > modifies symbols, so why not adding the functionality into kexec? The
> > advantage would be that there's no on-disk modification necessary.
> 
> Actually, 'embed_configfile /proc/kcore.info /vmlinux-kdump' makes
> no on-disk modification, since it is all contained in initramfs (we
> step out of initramfs in stage 5). 

Well, that assumes that you load the kdump kernel in the initrd of the
normal kernel. That's not always the case. For example, in SUSE the
kdump kernel is loaded as init script in the normal boot process.
Also, e.g. when testing, you may load the kdump kernel again. So you
would always need to copy the kdump kernel, modify it with
embed_configfile and then run kexec.

I think extending kexec to perform this task is more user friendly.

> BTW another option would be containing the whole CONFIGFILE as a 
> vmlinux-specific ELF note, to be easily read from /proc/vmcore.
> You'd still need some util like embed_configfile at build time 
> in order to integrate it, and you'd also need to modify 
> makedumpfile so it can use it. Actually this sounds quite better
> to me. I'll try to prepare patches both for makedumpfile and the 
> kernel and see how easy it is.

Well, in our kernel RPMs there's also a CONFIGFILE which can be
located on disk based on the version. (If a user builds the kernel
manually, then he probably builds it with -g anyway because if he
doesn't, he cannot run makedumpfile.)

The inclusion of the CONFIGFILE can be done by kexec when loading the
kdump kernel, either from a file or from the compiled-in
/proc/kcore.info file. I don't see a reason why a tool should modify
the vmlinux file for kdump on-disk.  Actually, I like the idea of
including a ELF note that contains CONFIGFILE.

Currently, we still have another problem: On x86_64, if the kernel is
relocatable, we only can use bzImage, not vmlinux kexec because of a
GDB bug that doesn't get attention by the GDB developers although I
found out the patch that broke GDB in that way ... But: That would
require that embed_configfile must also be able to modify bzImage
which is very problematic. Adding a ELF in kexec that could be read in
the /proc/vmcore hasn't that problem.



Thanks,
   Bernhard


From vgoyal at in.ibm.com  Tue Jul 10 11:00:37 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 10 Jul 2007 20:30:37 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070709114131.GA18750@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
Message-ID: <20070710150037.GB10216@in.ibm.com>

On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
> 
> I don't think it would add much complexity to build process as it 
> is now, just like the other tools that transparently do post-linking 
> modifications. As far as the developer is concerned, there's just
> the vmlinux and/or bzImage files that get emitted at the end.
> 
> > > Then inside initramfs of the first kernel, a small 
> > > util will modify the vmlinux file of the kdump kernel before it
> > > gets loaded so that another special file appearing as 
> > > /proc/vmcore.info under the kdump kernel will present the same
> > > info. 
> > 
> > Where do you get the info from? If you're in the kdump initrd,
> > then the kdump kernel is already loaded. Do you want to attach the
> > info from the crashed kernel to the initrd of the kdump kernel?
> 
> Not exactly. Let me describe the procedure in greater detail.
> Basically, it would go like this:
> 
> 1. <normal bootloader boot>
> 2. <normal initramfs>
> 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> 4. kexec -l vmlinux-kdump <....>
> 5. <boot continues>
> 6. <crash>
> 7. <kdump kernel boot>
> 8. <kdump initramfs runs>
> 9. makedumpfile -i /proc/vmcore.info <....>
> 
> NOTES:
> ** in step 3 embed_configfile modifies vmlinux-kdump in place, 
>    copying /proc/kcore.info into the data section of the vmlinux-kdump 
>    at certain symbol (e.g. 'char core_info[0x1000]').
> ** in step 9 that data section variable (e.g. core_info) which was 
>    originally holds the content of /proc/kcore.info is being presented 
>    as /proc/vmcore.info for the util to use.
> 
> To complete the picture, at the final build stage of vmlinux we 
> would have this:
> 
> makedumpfile -g vmlinux.configfile -x vmlinuxx
> embed_configfile vmlinux.configfile vmlinux
> rm vmlinux.configfile
> 

Are you planning to move makedumpfile utility in kernel source three then
for this command to run? Output of "makedumpfile -g" is pretty non-standard
and very customized for filtering. At the same time, this will only work
if first kernel was compiled with debug info. (I think makedumpfile
retrieves all the structure member offset info from .debuginfo seciton).

I am still thinking that why can't we change initrd building process
(Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
that while building an initrd/initramfs for the first kernel, one will
ask user for kdump kernel (if user wishes to load kdump kenrel through
initrd) and then it will generate kdump kenrel's initrd and pack into
first kernel's initrd.

So steps would look something like this.

- mkinitrd takes second kernel's vmlinux as argument
- mkinitrd runs "makedumpfile -g" on debug version of first kernel's vmlinux.
- mkinitrd generates the initramfs for kdump kernel and packs output
  of "makedumpfile -g" into that.
- mkinitrd packs statically linked kexec, kdump kernel vmlinux/bzImage,
  and kdump kernel initramfs into first kernel's initramfs.

This will save us from doing any changes to kernel build process and
also avoid any run time updation of vmlinux code. Exporting a particular
non-standard output through proc interfaces does not seem to be a very good
idea (/proc/kcore.info or /proc/vmcore.info)

Thanks
Vivek


From nhorman at redhat.com  Tue Jul 10 13:17:40 2007
From: nhorman at redhat.com (Neil Horman)
Date: Tue, 10 Jul 2007 13:17:40 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710150037.GB10216@in.ibm.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
Message-ID: <20070710171740.GA11130@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> On Mon, Jul 09, 2007 at 02:41:31PM +0300, Dan Aloni wrote:
> > 
> > I don't think it would add much complexity to build process as it 
> > is now, just like the other tools that transparently do post-linking 
> > modifications. As far as the developer is concerned, there's just
> > the vmlinux and/or bzImage files that get emitted at the end.
> > 
> > > > Then inside initramfs of the first kernel, a small 
> > > > util will modify the vmlinux file of the kdump kernel before it
> > > > gets loaded so that another special file appearing as 
> > > > /proc/vmcore.info under the kdump kernel will present the same
> > > > info. 
> > > 
> > > Where do you get the info from? If you're in the kdump initrd,
> > > then the kdump kernel is already loaded. Do you want to attach the
> > > info from the crashed kernel to the initrd of the kdump kernel?
> > 
> > Not exactly. Let me describe the procedure in greater detail.
> > Basically, it would go like this:
> > 
> > 1. <normal bootloader boot>
> > 2. <normal initramfs>
> > 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> > 4. kexec -l vmlinux-kdump <....>
> > 5. <boot continues>
> > 6. <crash>
> > 7. <kdump kernel boot>
> > 8. <kdump initramfs runs>
> > 9. makedumpfile -i /proc/vmcore.info <....>
> > 
> > NOTES:
> > ** in step 3 embed_configfile modifies vmlinux-kdump in place, 
> >    copying /proc/kcore.info into the data section of the vmlinux-kdump 
> >    at certain symbol (e.g. 'char core_info[0x1000]').
> > ** in step 9 that data section variable (e.g. core_info) which was 
> >    originally holds the content of /proc/kcore.info is being presented 
> >    as /proc/vmcore.info for the util to use.
> > 
> > To complete the picture, at the final build stage of vmlinux we 
> > would have this:
> > 
> > makedumpfile -g vmlinux.configfile -x vmlinuxx
> > embed_configfile vmlinux.configfile vmlinux
> > rm vmlinux.configfile
> > 
> 
> Are you planning to move makedumpfile utility in kernel source three then
> for this command to run? Output of "makedumpfile -g" is pretty non-standard
> and very customized for filtering. At the same time, this will only work
> if first kernel was compiled with debug info. (I think makedumpfile
> retrieves all the structure member offset info from .debuginfo seciton).
> 
I think that your step 3 doesn't make too much sense, unless you only run
kernels with dwarf debug information included, in which case you don't need to
embed any files, since the kdump kernel will expose all its needed symbol info
through /proc/kcore.  Currently the RHEL5 kdump service embeds the needed config
file into the kdump initramfs for use on kdump.  I don't see what added
advantage the above series of actions provides.

> I am still thinking that why can't we change initrd building process
> (Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
> that while building an initrd/initramfs for the first kernel, one will
> ask user for kdump kernel (if user wishes to load kdump kenrel through
> initrd) and then it will generate kdump kenrel's initrd and pack into
> first kernel's initrd.
> 
> So steps would look something like this.
> 
> - mkinitrd takes second kernel's vmlinux as argument
> - mkinitrd runs "makedumpfile -g" on debug version of first kernel's vmlinux.
> - mkinitrd generates the initramfs for kdump kernel and packs output
>   of "makedumpfile -g" into that.
> - mkinitrd packs statically linked kexec, kdump kernel vmlinux/bzImage,
>   and kdump kernel initramfs into first kernel's initramfs.
> 
Agreed, this is exactly what happens right now.

> This will save us from doing any changes to kernel build process and
> also avoid any run time updation of vmlinux code. Exporting a particular
> non-standard output through proc interfaces does not seem to be a very good
> idea (/proc/kcore.info or /proc/vmcore.info)
> 
> Thanks
> Vivek

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From da-x at monatomic.org  Tue Jul 10 13:35:41 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 20:35:41 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
	<20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
Message-ID: <20070710173541.GA21743@localdomain>

On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > I am still thinking that why can't we change initrd building process
> > (Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
> > that while building an initrd/initramfs for the first kernel, one will
> > ask user for kdump kernel (if user wishes to load kdump kenrel through
> > initrd) and then it will generate kdump kenrel's initrd and pack into
> > first kernel's initrd.
> > 
> > So steps would look something like this.
> > 
> > - mkinitrd takes second kernel's vmlinux as argument
> > - mkinitrd runs "makedumpfile -g" on debug version of first kernel's vmlinux.
> > - mkinitrd generates the initramfs for kdump kernel and packs output
> >   of "makedumpfile -g" into that.
> > - mkinitrd packs statically linked kexec, kdump kernel vmlinux/bzImage,
> >   and kdump kernel initramfs into first kernel's initramfs.
> > 
> Agreed, this is exactly what happens right now.

Isn't there some sort of a circular dependency going on here? As I 
understand it the vmlinux binary already contains the initramfs as 
built-in data (at least that's what I use here for initramfs). It 
makes more sense if you guys are creating an _initrd_ image (that's 
what mkinitrd originally did AFAIK) and supply it to the boot-loader.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From da-x at monatomic.org  Tue Jul 10 14:26:08 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 21:26:08 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710173541.GA21743@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
	<20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
	<20070710173541.GA21743@localdomain>
Message-ID: <20070710182608.GA2145@localdomain>

On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > > I am still thinking that why can't we change initrd building process
> > > (Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
> > > that while building an initrd/initramfs for the first kernel, one will
> > > ask user for kdump kernel (if user wishes to load kdump kenrel through
> > > initrd) and then it will generate kdump kenrel's initrd and pack into
> > > first kernel's initrd.
> > > 
> > > So steps would look something like this.
> > > 
> > > - mkinitrd takes second kernel's vmlinux as argument
> > > - mkinitrd runs "makedumpfile -g" on debug version of first kernel's vmlinux.
> > > - mkinitrd generates the initramfs for kdump kernel and packs output
> > >   of "makedumpfile -g" into that.
> > > - mkinitrd packs statically linked kexec, kdump kernel vmlinux/bzImage,
> > >   and kdump kernel initramfs into first kernel's initramfs.
> > > 
> > Agreed, this is exactly what happens right now.
> 
> Isn't there some sort of a circular dependency going on here? As I 
> understand it the vmlinux binary already contains the initramfs as 
> built-in data (at least that's what I use here for initramfs). It 
> makes more sense if you guys are creating an _initrd_ image (that's 
> what mkinitrd originally did AFAIK) and supply it to the boot-loader.

I see you are using an _external_ initramfs image. Sorry, I forgot 
that option existed...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From nhorman at redhat.com  Tue Jul 10 15:00:09 2007
From: nhorman at redhat.com (Neil Horman)
Date: Tue, 10 Jul 2007 15:00:09 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710173541.GA21743@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
	<20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
	<20070710173541.GA21743@localdomain>
Message-ID: <20070710190009.GB11130@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 01:17:40PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:30:37PM +0530, Vivek Goyal wrote:
> > > I am still thinking that why can't we change initrd building process
> > > (Be it mkinitrd or mkdumprd depending on distriution). Whole idea is
> > > that while building an initrd/initramfs for the first kernel, one will
> > > ask user for kdump kernel (if user wishes to load kdump kenrel through
> > > initrd) and then it will generate kdump kenrel's initrd and pack into
> > > first kernel's initrd.
> > > 
> > > So steps would look something like this.
> > > 
> > > - mkinitrd takes second kernel's vmlinux as argument
> > > - mkinitrd runs "makedumpfile -g" on debug version of first kernel's vmlinux.
> > > - mkinitrd generates the initramfs for kdump kernel and packs output
> > >   of "makedumpfile -g" into that.
> > > - mkinitrd packs statically linked kexec, kdump kernel vmlinux/bzImage,
> > >   and kdump kernel initramfs into first kernel's initramfs.
> > > 
> > Agreed, this is exactly what happens right now.
> 
> Isn't there some sort of a circular dependency going on here? As I 
> understand it the vmlinux binary already contains the initramfs as 
> built-in data (at least that's what I use here for initramfs). It 
You're misunderstood.  The vmlinux binary and the initramfs are stored in the
same protected memory area when you execute a kexec -l, but they are separate
and distinct files.

> makes more sense if you guys are creating an _initrd_ image (that's 
> what mkinitrd originally did AFAIK) and supply it to the boot-loader.
initrd is old, initramfs is the new way to go, but they effecitvley do the same
thing, and while the initramfs _can_ be built into the kernel, it can also be
separately managed (which is what most distros tend to do, AFAICS).
Neil

> 
> -- 
> Dan Aloni
> XIV LTD, http://www.xivstorage.com
> da-x (at) monatomic.org, dan (at) xiv.co.il

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From da-x at monatomic.org  Tue Jul 10 16:36:45 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 23:36:45 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710190009.GB11130@hmsendeavour.rdu.redhat.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
	<20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
	<20070710173541.GA21743@localdomain>
	<20070710190009.GB11130@hmsendeavour.rdu.redhat.com>
Message-ID: <20070710203645.GB22675@localdomain>

On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
>[...]
> > 
> > Isn't there some sort of a circular dependency going on here? As I 
> > understand it the vmlinux binary already contains the initramfs as 
> > built-in data (at least that's what I use here for initramfs). It 
> You're misunderstood.  The vmlinux binary and the initramfs are stored in the
> same protected memory area when you execute a kexec -l, but they are separate
> and distinct files.
> 
> > makes more sense if you guys are creating an _initrd_ image (that's 
> > what mkinitrd originally did AFAIK) and supply it to the boot-loader.
> initrd is old, initramfs is the new way to go, but they effecitvley do the same
> thing, and while the initramfs _can_ be built into the kernel, it can also be
> separately managed (which is what most distros tend to do, AFAICS).
> Neil

Yes, I was under the impression that the external initramfs was the 
'special case' and I seem to forget about it, I guess that's what most  
kernel distribution still do (I haven't been using a distribution-supplied 
kernel for quite a while...).

Anyway, the patches I contributed in one the previous mail (didn't reach 
the kexec list due to moderation but available on LKML) can help with 
what Bernhard is aiming for. I took quite a dive into makedumpfile's code 
to figure out what's the best way to integrate it. What I was thinking 
was something in the lines of:

 * early on, detect if /proc/vmcore has a LINUX elf note 
   * if it has, then don't require '-x' or '-i' on the command line,
     extract it to a temporary file and treat it as a CONFIGFILE for 
     the rest of the code flow.
   * otherwise, continue with the regular flow.

For just extracting OSRELEASE, it is possible to write a simple program or 
script that searches for it at the first few kilobytes of the file.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From da-x at monatomic.org  Tue Jul 10 12:52:01 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Tue, 10 Jul 2007 19:52:01 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
Message-ID: <20070710165201.GA7984@localdomain>

On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > > Hello,
[...]
> > > It contains enough information in order to make a compact kernel
> > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > you see, it also contains the kernel version.
> > > 
> > 
> > But this will not solve Bernhard's problem where looking at a vmcore
> > he wants to know which vmlinux (kernel version with time stamp) has
> > generated this vmcore. So adding a ELF NOTE should help.
> > 
> I think an ELF note would be a fine idea.

Okay, so here's an implemenation.

See the attached proof-of-concept patches to the kernel-side kexec and 
kexec-tools (might need some cleanup though). Next to follow, a patch 
to makedumpfile. With these patches a new "LINUX" elf note generated 
by the kernel in the format that makedumpfile expects and is being 
passed on by the kexec util to the kdump kernel.

As a bonus, with this patch you don't even have to compile the kernel 
with debug information in order for the filtering to work.

As Vivek mentioned in another mail, the output of makedumpfile is not
really a standard. However, I believe we should start making standards
where no standard exists. :)

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-kexec-mkdfinfo-note.diff
Type: text/x-diff
Size: 4918 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/kexec/attachments/20070710/faf7622c/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kexec-tools-mkdfinfo-note.diff
Type: text/x-diff
Size: 2849 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/kexec/attachments/20070710/faf7622c/attachment-0003.bin 

From vgoyal at in.ibm.com  Wed Jul 11 02:07:26 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Wed, 11 Jul 2007 11:37:26 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710165201.GA7984@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
	<20070710165201.GA7984@localdomain>
Message-ID: <20070711060726.GA5310@in.ibm.com>

On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > > > Hello,
> [...]
> > > > It contains enough information in order to make a compact kernel
> > > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > > you see, it also contains the kernel version.
> > > > 
> > > 
> > > But this will not solve Bernhard's problem where looking at a vmcore
> > > he wants to know which vmlinux (kernel version with time stamp) has
> > > generated this vmcore. So adding a ELF NOTE should help.
> > > 
> > I think an ELF note would be a fine idea.
> 
> Okay, so here's an implemenation.
> 
> See the attached proof-of-concept patches to the kernel-side kexec and 
> kexec-tools (might need some cleanup though). Next to follow, a patch 
> to makedumpfile. With these patches a new "LINUX" elf note generated 
> by the kernel in the format that makedumpfile expects and is being 
> passed on by the kexec util to the kdump kernel.
> 
> As a bonus, with this patch you don't even have to compile the kernel 
> with debug information in order for the filtering to work.
> 

This implementation looks interesting. No need of debug compiled
vmlinux for dump filtering purposes. No run time vmlinux binary modifications
as suggested by your previous mails. People can export kernel CONFIG info
like PAGESIZE etc with the help of this ELF note and any tool which is
processing kernel core file can benifit from this. No guesses required for
determining the page size of crashed kernel.

All the info required by dump filtering tool, put it into an ELF note, 
pass it to second kernel which appends it to final vmcore. The only concern
here again is that type of ELF note is not standard. The contents of 
ELF notes will keep on changing over a period of time. For example if a 
new memory model evolves. Now everytime this note data changes one shall
have to update mkdumpfile and user shall have to newer version. If there
are any issues, user will not come to know about the issue during kdump
service enablement time, instead it will be detected during dump 
capture time. It is too late till then.

I think we can make OSRELEASE info into a separate ELF note. Something
like a note type "UTS_RELEASE". This ELF note type then can also be 
reused for appending an ELF note to vmlinux to determine the kernel
version.
 

> As Vivek mentioned in another mail, the output of makedumpfile is not
> really a standard. However, I believe we should start making standards
> where no standard exists. :)
> 
> -- 
> Dan Aloni
> XIV LTD, http://www.xivstorage.com
> da-x (at) monatomic.org, dan (at) xiv.co.il

> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 8c2c7fc..a0412ce 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -121,6 +121,8 @@ extern struct page *kimage_alloc_control_pages(struct kimage *image,
>  extern void crash_kexec(struct pt_regs *);
>  int kexec_should_crash(struct task_struct *);
>  void crash_save_cpu(struct pt_regs *regs, int cpu);
> +void crash_save_mkdfinfo(void);
> +

We don't have to save this info in ELF note format after the crash. This
info gets fixed once kernel is booted. I think we should save it in some
init routine and not in crash_kexec().

>  extern struct kimage *kexec_image;
>  extern struct kimage *kexec_crash_image;
> 
> @@ -153,7 +155,10 @@ extern struct kimage *kexec_crash_image;
>  extern struct resource crashk_res;
>  typedef u32 note_buf_t[KEXEC_NOTE_BYTES/4];
>  extern note_buf_t *crash_notes;
> -
> +extern unsigned char mkdfinfo_data[MAX_NOTE_BYTES];
> +extern unsigned int mkdfinfo_size;
> +extern unsigned int mkdfinfo_max_size;
> +extern note_buf_t mkdfinfo_note;

mkdfinfo does not seem to be very appropriate name. We probably need to have a
better name. This all seems to be debug data (symbol info, structure size,
offsets of struct members) so how about "debuginfo"?

Thanks
Vivek


From da-x at monatomic.org  Wed Jul 11 03:32:16 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Wed, 11 Jul 2007 10:32:16 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070711060726.GA5310@in.ibm.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
	<20070710165201.GA7984@localdomain>
	<20070711060726.GA5310@in.ibm.com>
Message-ID: <20070711073216.GA11757@localdomain>

On Wed, Jul 11, 2007 at 11:37:26AM +0530, Vivek Goyal wrote:
> On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > > > > Hello,
> > [...]
> > > > > It contains enough information in order to make a compact kernel
> > > > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > > > you see, it also contains the kernel version.
> > > > > 
> > > > 
> > > > But this will not solve Bernhard's problem where looking at a vmcore
> > > > he wants to know which vmlinux (kernel version with time stamp) has
> > > > generated this vmcore. So adding a ELF NOTE should help.
> > > > 
> > > I think an ELF note would be a fine idea.
> > 
> > Okay, so here's an implemenation.
> > 
> > See the attached proof-of-concept patches to the kernel-side kexec and 
> > kexec-tools (might need some cleanup though). Next to follow, a patch 
> > to makedumpfile. With these patches a new "LINUX" elf note generated 
> > by the kernel in the format that makedumpfile expects and is being 
> > passed on by the kexec util to the kdump kernel.
> > 
> > As a bonus, with this patch you don't even have to compile the kernel 
> > with debug information in order for the filtering to work.
> > 
> 
> This implementation looks interesting. No need of debug compiled
> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
> as suggested by your previous mails. People can export kernel CONFIG info
> like PAGESIZE etc with the help of this ELF note and any tool which is
> processing kernel core file can benifit from this. No guesses required for
> determining the page size of crashed kernel.
> 
> All the info required by dump filtering tool, put it into an ELF note, 
> pass it to second kernel which appends it to final vmcore. The only concern
> here again is that type of ELF note is not standard. The contents of 
> ELF notes will keep on changing over a period of time. For example if a 
> new memory model evolves. Now everytime this note data changes one shall
> have to update mkdumpfile and user shall have to newer version. If there
> are any issues, user will not come to know about the issue during kdump
> service enablement time, instead it will be detected during dump 
> capture time. It is too late till then.

I guess that dump filtering will needed to be tested at least once 
under various platforms for every major release of the kernel to see 
if the information exported by the kernel through this elf note is 
still sufficient. 

Adding more info to this elf note as needed can be done through a simple 
patch to the kernel and it can be tested along with mkdumpfile changes 
even before a major version gets released.

More things to consider:

 * Elf note size is currently limited to 1024, we might need a bit more
   (currently this elf note is in the 900-area).
 * If we move the generation of the elf note to the boot time instead 
   of crash time as you suggested, we can also make it viewable as a 
   virtual file.
 * We should come up with a standard name for the note (LINUX, or 
   LINUX-VMCORE, etc).
 
> I think we can make OSRELEASE info into a separate ELF note. Something
> like a note type "UTS_RELEASE". This ELF note type then can also be 
> reused for appending an ELF note to vmlinux to determine the kernel
> version.

Agreed.

Actually, having a UTS_RELEASE note attached to vmlinux itself is quite 
easy to implement. All we need is some .s file in the kernel doing 
something similar to this (inspired by some post made by Ulrich Drepper):

#include <linux/utsrelease.h>

	.section ".note.UTS_RELEASE", "a"
	.align 4
	.long 1f - 0f		/* name length */
	.long 3f - 2f		/* data length */
	.long  1		/* note type */
0:	.asciz "UTS_RELEASE"	/* uts release */
1:	.align 4	
2:	.asciz UTS_RELEASE     	/* note data */
3:	.align 4		/* pad out section */

> We don't have to save this info in ELF note format after the crash. This
> info gets fixed once kernel is booted. I think we should save it in some
> init routine and not in crash_kexec().

Agreed.
 
> > +extern unsigned char mkdfinfo_data[MAX_NOTE_BYTES];
> > +extern unsigned int mkdfinfo_size;
> > +extern unsigned int mkdfinfo_max_size;
> > +extern note_buf_t mkdfinfo_note;
> 
> mkdfinfo does not seem to be very appropriate name. We probably need to have a
> better name. This all seems to be debug data (symbol info, structure size,
> offsets of struct members) so how about "debuginfo"?

'debuginfo' can be confused with the more standard DWARF debuginfo. 
How about vmcoreinfo, dumpinfo, debugaux, debugauxinfo, or 
dumpauxinfo?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From bwalle at suse.de  Wed Jul 11 04:58:10 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Wed, 11 Jul 2007 10:58:10 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070711060726.GA5310@in.ibm.com>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
	<20070710165201.GA7984@localdomain>
	<20070711060726.GA5310@in.ibm.com>
Message-ID: <20070711085810.GB23466@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-11 08:07]:
> On Tue, Jul 10, 2007 at 07:52:01PM +0300, Dan Aloni wrote:
> > On Tue, Jul 10, 2007 at 08:09:04AM -0400, Neil Horman wrote:
> > > On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> > > > On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> > > > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote:
> > > > > > Hello,
> > [...]
> > > > > It contains enough information in order to make a compact kernel
> > > > > dump (makedumpinfo needs to go over the struct page arrays). As
> > > > > you see, it also contains the kernel version.
> > > > > 
> > > > 
> > > > But this will not solve Bernhard's problem where looking at a vmcore
> > > > he wants to know which vmlinux (kernel version with time stamp) has
> > > > generated this vmcore. So adding a ELF NOTE should help.
> > > > 
> > > I think an ELF note would be a fine idea.
> > 
> > Okay, so here's an implemenation.
> > 
> > See the attached proof-of-concept patches to the kernel-side kexec and 
> > kexec-tools (might need some cleanup though). Next to follow, a patch 
> > to makedumpfile. With these patches a new "LINUX" elf note generated 
> > by the kernel in the format that makedumpfile expects and is being 
> > passed on by the kexec util to the kdump kernel.
> > 
> > As a bonus, with this patch you don't even have to compile the kernel 
> > with debug information in order for the filtering to work.
> > 
> 
> This implementation looks interesting. No need of debug compiled
> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
> as suggested by your previous mails. People can export kernel CONFIG info
> like PAGESIZE etc with the help of this ELF note and any tool which is
> processing kernel core file can benifit from this. No guesses required for
> determining the page size of crashed kernel.

I also like way of implementing it. :)


Thanks,
   Bernhard


From nhorman at redhat.com  Wed Jul 11 07:57:29 2007
From: nhorman at redhat.com (Neil Horman)
Date: Wed, 11 Jul 2007 07:57:29 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710203645.GB22675@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070709092154.GA19705@suse.de>
	<20070709114131.GA18750@localdomain>
	<20070710150037.GB10216@in.ibm.com>
	<20070710171740.GA11130@hmsendeavour.rdu.redhat.com>
	<20070710173541.GA21743@localdomain>
	<20070710190009.GB11130@hmsendeavour.rdu.redhat.com>
	<20070710203645.GB22675@localdomain>
Message-ID: <20070711115729.GA6685@hmsendeavour.rdu.redhat.com>

On Tue, Jul 10, 2007 at 11:36:45PM +0300, Dan Aloni wrote:
> On Tue, Jul 10, 2007 at 03:00:09PM -0400, Neil Horman wrote:
> > On Tue, Jul 10, 2007 at 08:35:41PM +0300, Dan Aloni wrote:
> >[...]
> > > 
> > > Isn't there some sort of a circular dependency going on here? As I 
> > > understand it the vmlinux binary already contains the initramfs as 
> > > built-in data (at least that's what I use here for initramfs). It 
> > You're misunderstood.  The vmlinux binary and the initramfs are stored in the
> > same protected memory area when you execute a kexec -l, but they are separate
> > and distinct files.
> > 
> > > makes more sense if you guys are creating an _initrd_ image (that's 
> > > what mkinitrd originally did AFAIK) and supply it to the boot-loader.
> > initrd is old, initramfs is the new way to go, but they effecitvley do the same
> > thing, and while the initramfs _can_ be built into the kernel, it can also be
> > separately managed (which is what most distros tend to do, AFAICS).
> > Neil
> 
> Yes, I was under the impression that the external initramfs was the 
> 'special case' and I seem to forget about it, I guess that's what most  
> kernel distribution still do (I haven't been using a distribution-supplied 
> kernel for quite a while...).
> 
> Anyway, the patches I contributed in one the previous mail (didn't reach 
> the kexec list due to moderation but available on LKML) can help with 
> what Bernhard is aiming for. I took quite a dive into makedumpfile's code 
> to figure out what's the best way to integrate it. What I was thinking 
> was something in the lines of:
> 
>  * early on, detect if /proc/vmcore has a LINUX elf note 
>    * if it has, then don't require '-x' or '-i' on the command line,
>      extract it to a temporary file and treat it as a CONFIGFILE for 
>      the rest of the code flow.
>    * otherwise, continue with the regular flow.
> 
This would make sense to me.

> For just extracting OSRELEASE, it is possible to write a simple program or 
> script that searches for it at the first few kilobytes of the file.
> 
Also seems reasonable.

Regards
Neil

> -- 
> Dan Aloni
> XIV LTD, http://www.xivstorage.com
> da-x (at) monatomic.org, dan (at) xiv.co.il

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From oomichi at mxs.nes.nec.co.jp  Wed Jul 11 09:43:04 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Wed, 11 Jul 2007 22:43:04 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070711073216.GA11757@localdomain>
References: <20070711073216.GA11757@localdomain>
Message-ID: <20070711224304oomichi@mail.jp.nec.com>


Hi Dan,

2007/07/11 10:32:16 +0300, Dan Aloni <da-x at monatomic.org> wrote:
>> This implementation looks interesting. No need of debug compiled
>> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
>> as suggested by your previous mails. People can export kernel CONFIG info
>> like PAGESIZE etc with the help of this ELF note and any tool which is
>> processing kernel core file can benifit from this. No guesses required for
>> determining the page size of crashed kernel.
>> 
>> All the info required by dump filtering tool, put it into an ELF note, 
>> pass it to second kernel which appends it to final vmcore. The only concern
>> here again is that type of ELF note is not standard. The contents of 
>> ELF notes will keep on changing over a period of time. For example if a 
>> new memory model evolves. Now everytime this note data changes one shall
>> have to update mkdumpfile and user shall have to newer version. If there
>> are any issues, user will not come to know about the issue during kdump
>> service enablement time, instead it will be detected during dump 
>> capture time. It is too late till then.
>
>I guess that dump filtering will needed to be tested at least once 
>under various platforms for every major release of the kernel to see 
>if the information exported by the kernel through this elf note is 
>still sufficient. 
>
>Adding more info to this elf note as needed can be done through a simple 
>patch to the kernel and it can be tested along with mkdumpfile changes 
>even before a major version gets released.

As Vivek said, I think it is not a good idea that both kernel's code and
makedumpfile's code should be changed when makedumpfile needs more debug
information (ex. To extend the supported CPU architectures. To fix some
machine-specific problems, etc.).
Also it is difficult to change the list of necessary items in kernel,
because we should be careful about CPU architecture, linux version, and
memory model. makedumpfile needs the following items, and those existence
depends on CPU architecture, linux version, and memory model. If we don't
be careful about them, the kernel building may fail.
I think it is not a good idea that each items are defined by ifdef, it
is too complex.

* Symbols
  - mem_map
  - mem_section
  - pkmap_count
  - system_utsname
  - init_uts_ns
  - _stext
  - swapper_pg_dir
  - phys_base
  - node_online_map
  - node_data
  - pgdat_list
  - contig_page_data

* Structure sizes
  - page
  - mem_section
  - pglist_data
  - zone
  - free_area
  - list_head

* Field offsets
  - page.flags
  - page._count
  - page.mapping
  - page.lru
  - mem_section.section_mem_map
  - pglist_data.node_zones
  - pglist_data.nr_zones
  - pglist_data.node_mem_map
  - pglist_data.node_start_pfn
  - pglist_data.node_spanned_pages
  - pglist_data.pgdat_next
  - zone.free_pages
  - zone.free_area
  - zone.vm_stat
  - zone.spanned_pages
  - free_area.free_list
  - list_head.next
  - list_head.prev

* The numbers of array
  - mem_section
  - pgdat_list
  - node_data
  - zone.free_area


I'd like to know your motivation for this work.
I think you don't want to manage an extra file (mkdfinfo file) besides
a vmlinux file from distributor's point of view, right ?


Thanks
Ken'ichi Ohmichi


From tony.luck at intel.com  Wed Jul 11 16:34:05 2007
From: tony.luck at intel.com (Luck, Tony)
Date: Wed, 11 Jul 2007 13:34:05 -0700
Subject: [IA64] [kdump] machveg=dig on hpzx1 platforms
In-Reply-To: <467AE260.7030906@hp.com>
Message-ID: <617E1C2C70743745A92448908E030B2A01E6CC56@scsmsx411.amr.corp.intel.com>

> Here is a patch to do that.  We use this internally, but
> I had forgotten to post it.

Terry,

Just got to applying some older patches ... perhaps this one has
been sitting too long because I had some apply & build problems with it.

Building with arch/ia64/configs/zx1_defconfig and with this patch
hand applied I get:

  LD      .tmp_vmlinux1
arch/ia64/hp/common/built-in.o(.init.text+0xcc2): In function `sba_init':
: undefined reference to `swiotlb_late_init_with_default_size'
arch/ia64/hp/common/built-in.o(.init.text+0xd02): In function `sba_init':
: undefined reference to `machvec_init'
make: *** [.tmp_vmlinux1] Error 1

sba_init() uses these routines inside #ifdef CONFIG_I64_GENERIC, perhaps
you need to do the same?


Other issues:
1) No "Signed-off-by"

2) +#include <linux/crash_dump.h>

We usually group all the <linux/*> includes together before the <asm/*> ones

3) +extern int swiotlb_late_init_with_default_size (size_t size);

extern declarations in ".c" files are frowned upon.  This should be in
a header file, which should be included (though I see that this guideline
has already been ignored as you were just moving the declaration).

-Tony


From ebiederm at xmission.com  Thu Jul 12 12:32:45 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 12 Jul 2007 10:32:45 -0600
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <1184251423.9346.55.camel@caritas-dev.intel.com> (Ying Huang's
	message of "Thu, 12 Jul 2007 14:43:43 +0000")
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
Message-ID: <m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>


I like the concept, but I completely disagree with your current
implementation.

I think it will be much easier if you start with a completely
independent code path and then just reuse the pieces of the
existing code path that you need.  

More details below.

"Huang, Ying" <ying.huang at intel.com> writes:

> On Wed, 2007-07-11 at 17:22 -0700, Andrew Morton wrote:
>> This sounds awesome.  Am I correct in expecting that ultimately the
>> existing hibernation implementation just goes away and we reuse (and hence
>> strengthen) the existing kexec (and kdump?) infrastructure?
>> And that we get hibernation support almost for free on all kexec (and
>> relocatable-kernel?) capable architectures?
>> And that all the management of hibernation and resume happens in userspace?
>
> Yes. Ultimately, most of the hibernation code such as process freezer,
> memory shrinking, memory snapshot (atomic copy), image reading/writing
> can go away, because kexec based hibernation doesn't depend on them.
> Just the device/CPU state quiescent/save/restore is necessary to remain.
> And, the management of hibernation and resume will happen in userspace.
>
>> I didn't understand the ACPI problem.  Does this mean that CONFIG_ACPI must
>> be disabled in the to-be-hibernated kernel, or in the little transient
>> kexec kernel?
>
> Under current implementation of device state quiescent/save/restore, the
> CONFIG_ACPI must be turned off both in to-be-hibernated kernel and
> transient kexec kernel.
>
> But the hibernation people are going to separate the device suspend from
> device hibernate. The device hibernate will put device in quiescent
> state but not in low power state. When this is done, it is not necessary
> to disable CONFIG_ACPI at all. It is just a workaround for current
> implementation that disabling CONFIG_ACPI.
>
>> How close do you think all this is to being a viable thing?
>
> The kexec jump is the first step, maybe the simplest step. There are
> many other issues to be resolved, at least the following ones.
>
> 1. Separate device suspend from device hibernate.

Actually in some very practical sense we already have two copies of
this in the kernel.  device_shutdown and the hotunplug/module
remove code.  So it is should be mostly a matter of using what we have.

Basically all this entails is to modify sys_reboot()
and adding a LINUX_REBOOT_CMD_KSPAWN and have that command
enter the kexec path with the appropriate set of calls.
I would be really surprised if this winds up with much
more code then the current kernel_kexec function.

This might wind up exactly the same as the current
LINUX_REBOOT_CMD_KEXEC but at least until we have a working
prototype it makes sense to allow for differences.

This should allow the kexec based implementation to coincide
with the existing software suspend to disk code until it is proven out
and then we can just remove all of the software suspend code to
disk code.

> 2. Do not reserve memory for kexec kernel. That is, backup needed memory
> before kexec and restore them after kexec.
> 3. Support the in-place kexec? The relocatable kernel is not necessary
> if this can be implemented.

It sounds like what you really want is the normal kexec path enhanced
so that you can return to the kernel you started with.

The normal kexec path already knows how to do the memory shuffle so
it can do on demand memory allocation.  That code just needs to
enhanced slightly so that you allocate an extra page, setup an inverse
scatter gather list for restoring the pages, and teach relocate_kernel.S
to preserve it's destination pages by using the inverse scatter gather
list.

The normal kexec path already calls device_shutdown and the like to
stop devices from running.  Although again that code path is not
prepared to restore the devices.

...

For prototyping I would:
- reserve a chunk of memory (possibly with the crashkernel= option)
  and run a relocatable kernel out of it.  

  By using the normal kexec you can boot a relocatable restore kernel
  in that reserved region. It is an extra step but it makes things
  work today.

- I would use the normal sys_kexec_load.

- I would debug/tweak the user space and the code to reenter the
  old kernel.  I.e. the device driver stop/start code.

  Once it was basically working I would the update normal kexec
  memory copy code in relocate.S to preserve the destination pages.

> 4. Image writing/reading. (Only user space application is needed).

And possibly a few fixes to /dev/mem.  This is pretty much the same
process as generating a core dump so there should be some synergy with that.

We probably want to use something like the ELF header the crashdump
path uses to communicate to the kernel saving memory which memory
regions need to be saved.  Which probably means that we you can use the
exact same method as the kexec on panic kernel uses to save memory.

> 5. A smooth resume process. Maybe it is not needed to kexec a new kernel
> for resume. For example, in the first stage of kernel boot, just first
> 16M (or a little more) RAM is used, if the resume image is found, the
> saved kernel image is resumed; if the resume image is not found, turn on
> the remaining RAM. This will depends on 3.

Well I expect the resume will be load the resumed kernel into reserved
memory.  And kexec a very small assembly stub that will jump back
to the code in relocate_kernel.S which will call ret.

Then either hot add the rest of our memory or kexec to a kernel without
restrictions.

> 6. Reduce the boot-up time of kexec kernel. Maybe the kexec kernel can
> be hibernate/resume by the normal kernel too. This way, a real
> kexec/boot-up is only needed for the first time.

Well just not loading drivers you aren't going to use and generally avoiding
long disk probing times will help here.  We control all of the code so
it should be relatively straight forward.

Eric


From terry.loftin at hp.com  Thu Jul 12 13:33:35 2007
From: terry.loftin at hp.com (Terry Loftin)
Date: Thu, 12 Jul 2007 11:33:35 -0600
Subject: [IA64] [kdump] machveg=dig on hpzx1 platforms
In-Reply-To: <617E1C2C70743745A92448908E030B2A01E6CC56@scsmsx411.amr.corp.intel.com>
References: <617E1C2C70743745A92448908E030B2A01E6CC56@scsmsx411.amr.corp.intel.com>
Message-ID: <469665EF.7060201@hp.com>

Luck, Tony wrote:

> 
> Just got to applying some older patches ... perhaps this one has
> been sitting too long because I had some apply & build problems with it.
> 
Sorry - I'd meant to attend to this but got distracted.
I'll repost it shortly and address the issues you mentioned.

-T


From terry.loftin at hp.com  Thu Jul 12 19:23:22 2007
From: terry.loftin at hp.com (Terry Loftin)
Date: Thu, 12 Jul 2007 17:23:22 -0600
Subject: [PATCH][IA64][kdump] use machvec=dig on hpzx1 platforms
Message-ID: <4696B7EA.6030009@hp.com>

Tony,

This is a cleaned up version of the machvec=dig patch:
* added CONFIG_IA64_GENERIC to avoid the compile problems, and
   test built with different config combinations
* moved include declaration to be consistent
* got review and sign off from Alex Williamson as well.
* +extern int swiotlb_late_init_with_default_size (size_t size);
   I left this because there is no applicable header file.
   I'm no fan of extern declarations either, but I didn't want to
   add a header just for this declaration, nor modify the machvec
   headers just to accommodate this hack.

Thanks!

-T

Patch Description:

On HP zx1 machines, the 'machvec=dig' parameter is needed for the
kdump kernel to avoid problems with the HP sba iommu.  The problem
is that during the boot of the kdump kernel, the iommu is re-initialized,
so in-flight DMA from improperly shutdown drivers causes an IOTLB
miss which leads to an MCA.  With kdump, the idea is to get into the
kdump kernel with as little code as we can, so shutting down drivers
properly is not an option.

The workaround is to add 'machvec=dig' to the kdump kernel boot
parameters.  This makes the kdump kernel avoid using the sba iommu
altogether, leaving the IOTLB intact.  Any ongoing DMA falls
harmlessly outside the kdump kernel.  After the kdump kernel reboots,
all devices will have been shutdown properly and DMA stopped.

This patch pushes that functionality into the sba iommu
initialization code, so that users won't have to find the obscure
documentation telling them about 'machvec=dig'.

This patch only affects HP platforms.  It still includes one
extern declaration in the file, because no applicable header file
exists.

Signed-off-by: Terry Loftin <terry.loftin at hp.com>
Signed-off-by: Alex Williamson <alex.williamson at hp.com>
---

diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index c1dca22..6abc080 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -34,6 +34,7 @@ #include <linux/acpi.h>
  #include <linux/efi.h>
  #include <linux/nodemask.h>
  #include <linux/bitops.h>         /* hweight64() */
+#include <linux/crash_dump.h>

  #include <asm/delay.h>		/* ia64_get_itc() */
  #include <asm/io.h>
@@ -43,6 +44,8 @@ #include <asm/system.h>		/* wmb() */

  #include <asm/acpi-ext.h>

+extern int swiotlb_late_init_with_default_size (size_t size);
+
  #define PFX "IOC: "

  /*
@@ -2026,11 +2029,24 @@ sba_init(void)
  	if (!ia64_platform_is("hpzx1") && !ia64_platform_is("hpzx1_swiotlb"))
  		return 0;

+#if defined(CONFIG_IA64_GENERIC) && defined(CONFIG_CRASH_DUMP)
+	/* If we are booting a kdump kernel, the sba_iommu will
+	 * cause devices that were not shutdown properly to MCA
+	 * as soon as they are turned back on.  Our only option for
+	 * a successful kdump kernel boot is to use the swiotlb.
+	 */
+	if (elfcorehdr_addr < ELFCORE_ADDR_MAX) {
+		if (swiotlb_late_init_with_default_size(64 * (1<<20)) != 0)
+			panic("Unable to initialize software I/O TLB:"
+				  " Try machvec=dig boot option");
+		machvec_init("dig");
+		return 0;
+	}
+#endif
+
  	acpi_bus_register_driver(&acpi_sba_ioc_driver);
  	if (!ioc_list) {
  #ifdef CONFIG_IA64_GENERIC
-		extern int swiotlb_late_init_with_default_size (size_t size);
-
  		/*
  		 * If we didn't find something sba_iommu can claim, we
  		 * need to setup the swiotlb and switch to the dig machvec.




From david at lang.hm  Thu Jul 12 15:09:31 2007
From: david at lang.hm (david at lang.hm)
Date: Thu, 12 Jul 2007 12:09:31 -0700 (PDT)
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
	<m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
Message-ID: <Pine.LNX.4.64.0707121206240.25614@asgard.lang.hm>

On Thu, 12 Jul 2007, Eric W. Biederman wrote:

>> 2. Do not reserve memory for kexec kernel. That is, backup needed memory
>> before kexec and restore them after kexec.
>> 3. Support the in-place kexec? The relocatable kernel is not necessary
>> if this can be implemented.
>
> It sounds like what you really want is the normal kexec path enhanced
> so that you can return to the kernel you started with.
>
> The normal kexec path already knows how to do the memory shuffle so
> it can do on demand memory allocation.  That code just needs to
> enhanced slightly so that you allocate an extra page, setup an inverse
> scatter gather list for restoring the pages, and teach relocate_kernel.S
> to preserve it's destination pages by using the inverse scatter gather
> list.
>
> The normal kexec path already calls device_shutdown and the like to
> stop devices from running.  Although again that code path is not
> prepared to restore the devices.

we shouldn't need a restore code path if the new kernel re-detects 
everything. if kexec already shuts down all the devices we may not need to 
implement anything new here (although there may be room for future 
performance optimization)

> ...
>
> For prototyping I would:
> - reserve a chunk of memory (possibly with the crashkernel= option)
>  and run a relocatable kernel out of it.
>
>  By using the normal kexec you can boot a relocatable restore kernel
>  in that reserved region. It is an extra step but it makes things
>  work today.
>
> - I would use the normal sys_kexec_load.
>
> - I would debug/tweak the user space and the code to reenter the
>  old kernel.  I.e. the device driver stop/start code.
>
>  Once it was basically working I would the update normal kexec
>  memory copy code in relocate.S to preserve the destination pages.

for prototyping there's no need to use the same kernel.

>> 4. Image writing/reading. (Only user space application is needed).
>
> And possibly a few fixes to /dev/mem.  This is pretty much the same
> process as generating a core dump so there should be some synergy with that.

what fixes are you thinking of?

you are makeing this sound very simple ;-)

David Lang


From ebiederm at xmission.com  Thu Jul 12 15:49:59 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 12 Jul 2007 13:49:59 -0600
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <Pine.LNX.4.64.0707121206240.25614@asgard.lang.hm>
	(david@lang.hm's message of "Thu, 12 Jul 2007 12:09:31 -0700 (PDT)")
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
	<m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
	<Pine.LNX.4.64.0707121206240.25614@asgard.lang.hm>
Message-ID: <m1sl7te714.fsf@ebiederm.dsl.xmission.com>

david at lang.hm writes:

> On Thu, 12 Jul 2007, Eric W. Biederman wrote:
>
>>> 2. Do not reserve memory for kexec kernel. That is, backup needed memory
>>> before kexec and restore them after kexec.
>>> 3. Support the in-place kexec? The relocatable kernel is not necessary
>>> if this can be implemented.
>>
>> It sounds like what you really want is the normal kexec path enhanced
>> so that you can return to the kernel you started with.
>>
>> The normal kexec path already knows how to do the memory shuffle so
>> it can do on demand memory allocation.  That code just needs to
>> enhanced slightly so that you allocate an extra page, setup an inverse
>> scatter gather list for restoring the pages, and teach relocate_kernel.S
>> to preserve it's destination pages by using the inverse scatter gather
>> list.
>>
>> The normal kexec path already calls device_shutdown and the like to
>> stop devices from running.  Although again that code path is not
>> prepared to restore the devices.
>
> we shouldn't need a restore code path if the new kernel re-detects
> everything. if kexec already shuts down all the devices we may not need to
> implement anything new here (although there may be room for future performance
> optimization)

Yes, reusing device hotplug...  You still need the code path for little
things and to kick of the device redetection but if you get lucky
it won't have to do much.  Of course speed is important.

>> ...
>>
>> For prototyping I would:
>> - reserve a chunk of memory (possibly with the crashkernel= option)
>>  and run a relocatable kernel out of it.
>>
>>  By using the normal kexec you can boot a relocatable restore kernel
>>  in that reserved region. It is an extra step but it makes things
>>  work today.
>>
>> - I would use the normal sys_kexec_load.
>>
>> - I would debug/tweak the user space and the code to reenter the
>>  old kernel.  I.e. the device driver stop/start code.
>>
>>  Once it was basically working I would the update normal kexec
>>  memory copy code in relocate.S to preserve the destination pages.
>
> for prototyping there's no need to use the same kernel.
>
>>> 4. Image writing/reading. (Only user space application is needed).
>>
>> And possibly a few fixes to /dev/mem.  This is pretty much the same
>> process as generating a core dump so there should be some synergy with that.
>
> what fixes are you thinking of?

Don't really know.  I figured /dev/mem was sufficient but the kexec
on panic folks tell me it doesn't work for areas we have told the kernel
isn't memory, I haven't had time so I haven't pushed it.

> you are makeing this sound very simple ;-)

Which is the primary point of using kexec.  If it isn't simple then we
are doing something wrong...

Eric


From vgoyal at in.ibm.com  Thu Jul 12 23:43:58 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Fri, 13 Jul 2007 09:13:58 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070711073216.GA11757@localdomain>
References: <20070706132814.GA7079@suse.de>
	<20070706145804.GA31409@localdomain>
	<20070710064817.GC5471@in.ibm.com>
	<20070710120904.GB10121@hmsendeavour.rdu.redhat.com>
	<20070710165201.GA7984@localdomain>
	<20070711060726.GA5310@in.ibm.com>
	<20070711073216.GA11757@localdomain>
Message-ID: <20070713034358.GA4975@in.ibm.com>

On Wed, Jul 11, 2007 at 10:32:16AM +0300, Dan Aloni wrote:
[..]
> > This implementation looks interesting. No need of debug compiled
> > vmlinux for dump filtering purposes. No run time vmlinux binary modifications
> > as suggested by your previous mails. People can export kernel CONFIG info
> > like PAGESIZE etc with the help of this ELF note and any tool which is
> > processing kernel core file can benifit from this. No guesses required for
> > determining the page size of crashed kernel.
> > 
> > All the info required by dump filtering tool, put it into an ELF note, 
> > pass it to second kernel which appends it to final vmcore. The only concern
> > here again is that type of ELF note is not standard. The contents of 
> > ELF notes will keep on changing over a period of time. For example if a 
> > new memory model evolves. Now everytime this note data changes one shall
> > have to update mkdumpfile and user shall have to newer version. If there
> > are any issues, user will not come to know about the issue during kdump
> > service enablement time, instead it will be detected during dump 
> > capture time. It is too late till then.
> 
> I guess that dump filtering will needed to be tested at least once 
> under various platforms for every major release of the kernel to see 
> if the information exported by the kernel through this elf note is 
> still sufficient. 
> 
> Adding more info to this elf note as needed can be done through a simple 
> patch to the kernel and it can be tested along with mkdumpfile changes 
> even before a major version gets released.
> 
> More things to consider:
> 
>  * Elf note size is currently limited to 1024, we might need a bit more
>    (currently this elf note is in the 900-area).

How about putting all the required info in a structure and then do
sizeof(struct) and reserve that much of memory at compile time for the
note. This will mean there are no hardcodings about the size of the note.

But I guess, one shall have to keep user space kexec-tools in sync to
create a PT_NOTE for that. May be exporting this info in header files to
user space might help.

>  * If we move the generation of the elf note to the boot time instead 
>    of crash time as you suggested, we can also make it viewable as a 
>    virtual file.

That would make sense. In that case, makedumpfile can do some verification
on the exported data and scream if something is not right at kdump service
start time.

>  * We should come up with a standard name for the note (LINUX, or 
>    LINUX-VMCORE, etc).
> 

How about VMCOREINFO?

> > I think we can make OSRELEASE info into a separate ELF note. Something
> > like a note type "UTS_RELEASE". This ELF note type then can also be 
> > reused for appending an ELF note to vmlinux to determine the kernel
> > version.
> 
> Agreed.
> 
> Actually, having a UTS_RELEASE note attached to vmlinux itself is quite 
> easy to implement. All we need is some .s file in the kernel doing 
> something similar to this (inspired by some post made by Ulrich Drepper):
> 
> #include <linux/utsrelease.h>
> 
> 	.section ".note.UTS_RELEASE", "a"
> 	.align 4
> 	.long 1f - 0f		/* name length */
> 	.long 3f - 2f		/* data length */
> 	.long  1		/* note type */
> 0:	.asciz "UTS_RELEASE"	/* uts release */
> 1:	.align 4	
> 2:	.asciz UTS_RELEASE     	/* note data */
> 3:	.align 4		/* pad out section */
> 
> > We don't have to save this info in ELF note format after the crash. This
> > info gets fixed once kernel is booted. I think we should save it in some
> > init routine and not in crash_kexec().
> 
> Agreed.
> 
> > > +extern unsigned char mkdfinfo_data[MAX_NOTE_BYTES];
> > > +extern unsigned int mkdfinfo_size;
> > > +extern unsigned int mkdfinfo_max_size;
> > > +extern note_buf_t mkdfinfo_note;
> > 
> > mkdfinfo does not seem to be very appropriate name. We probably need to have a
> > better name. This all seems to be debug data (symbol info, structure size,
> > offsets of struct members) so how about "debuginfo"?
> 
> 'debuginfo' can be confused with the more standard DWARF debuginfo. 
> How about vmcoreinfo, dumpinfo, debugaux, debugauxinfo, or 
> dumpauxinfo?
> 

To me vmcoreinfo looks like a good name to begin with. As of today vmcore
is the only consumer of the info. We might have to migrate to a more generic
name down the line if consumers of the info pop-up.

Thanks
Vivek


From vgoyal at in.ibm.com  Thu Jul 12 23:58:25 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Fri, 13 Jul 2007 09:28:25 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070711224304oomichi@mail.jp.nec.com>
References: <20070711073216.GA11757@localdomain>
	<20070711224304oomichi@mail.jp.nec.com>
Message-ID: <20070713035825.GB4975@in.ibm.com>

On Wed, Jul 11, 2007 at 10:43:04PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi Dan,
> 
> 2007/07/11 10:32:16 +0300, Dan Aloni <da-x at monatomic.org> wrote:
> >> This implementation looks interesting. No need of debug compiled
> >> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
> >> as suggested by your previous mails. People can export kernel CONFIG info
> >> like PAGESIZE etc with the help of this ELF note and any tool which is
> >> processing kernel core file can benifit from this. No guesses required for
> >> determining the page size of crashed kernel.
> >> 
> >> All the info required by dump filtering tool, put it into an ELF note, 
> >> pass it to second kernel which appends it to final vmcore. The only concern
> >> here again is that type of ELF note is not standard. The contents of 
> >> ELF notes will keep on changing over a period of time. For example if a 
> >> new memory model evolves. Now everytime this note data changes one shall
> >> have to update mkdumpfile and user shall have to newer version. If there
> >> are any issues, user will not come to know about the issue during kdump
> >> service enablement time, instead it will be detected during dump 
> >> capture time. It is too late till then.
> >
> >I guess that dump filtering will needed to be tested at least once 
> >under various platforms for every major release of the kernel to see 
> >if the information exported by the kernel through this elf note is 
> >still sufficient. 
> >
> >Adding more info to this elf note as needed can be done through a simple 
> >patch to the kernel and it can be tested along with mkdumpfile changes 
> >even before a major version gets released.
> 
> As Vivek said, I think it is not a good idea that both kernel's code and
> makedumpfile's code should be changed when makedumpfile needs more debug
> information (ex. To extend the supported CPU architectures. To fix some
> machine-specific problems, etc.).
> Also it is difficult to change the list of necessary items in kernel,
> because we should be careful about CPU architecture, linux version, and
> memory model. makedumpfile needs the following items, and those existence
> depends on CPU architecture, linux version, and memory model. If we don't
> be careful about them, the kernel building may fail.
> I think it is not a good idea that each items are defined by ifdef, it
> is too complex.
> 

Hi Ken'ichi,

This approach seems to have advantages also. For example, now one will not
require a kernel debuginfo file to configure kdump with dump filtering.
I think having to have a debug info file is a big restriction.

Now vmcore ELF note contain all the data rquired to filter core dump and
there will be no need to parse DWARF debuginfo and makedumpfile code will be
smaller and simpler.

Given the fact that more and more architectures are supporting multiple
page sizes. Now one can also export relevant kernel CONFIG variables
through this ELF note. makedumpfile's job will be simpler. You don't have
to make any guesses about various config options like page size.

This approach will make second kernel truly independent of first kernel.
Currently, if first kernel changes one shall have to regenerate the 
initrd for second kenrel. Hence in a sense, second kernel is dependent on
first kernel. Now kernel will export all the required data for dump filtering
so one does not have to rebuild the seond kernel initrd even if first kernel
changes.

I think overall the approach of exporting right info from kernel should 
help. Only thing is that we shall have to manage the ELF note better in
terms of making it more generic.

Thanks
Vivek


From bwalle at suse.de  Fri Jul 13 03:49:27 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Fri, 13 Jul 2007 09:49:27 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070713035825.GB4975@in.ibm.com>
References: <20070711073216.GA11757@localdomain>
	<20070711224304oomichi@mail.jp.nec.com>
	<20070713035825.GB4975@in.ibm.com>
Message-ID: <20070713074927.GA15920@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-13 05:58]:
> Given the fact that more and more architectures are supporting multiple
> page sizes. Now one can also export relevant kernel CONFIG variables
> through this ELF note. makedumpfile's job will be simpler. You don't have
> to make any guesses about various config options like page size.
> 
> This approach will make second kernel truly independent of first kernel.
> Currently, if first kernel changes one shall have to regenerate the 
> initrd for second kenrel. Hence in a sense, second kernel is dependent on
> first kernel. Now kernel will export all the required data for dump filtering
> so one does not have to rebuild the seond kernel initrd even if first kernel
> changes.

That's only the RedHat mechanism. You can copy all CONFIGFILEs to the
initrd, and then pick the right one via the version. Then, you only
have to regenerate the initrd when you *install* a new first kernel,
not when you boot a new first kernel. And that's also why I wanted the
kernel version to be accessible in the crashkernel ...

> I think overall the approach of exporting right info from kernel should 
> help. Only thing is that we shall have to manage the ELF note better in
> terms of making it more generic.

Basically I like the idea of exporting the information from the kernel
without generating the CONFIGFILE. The only big problem I see that the
makedumpfile release cycles would depend on the kernel release cycles,
and, you cannot add new features to makedumpfile for old kernels since
you always rely on the information which is exported.


Thanks,
   Bernhard


From horms at verge.net.au  Fri Jul 13 04:55:35 2007
From: horms at verge.net.au (Horms)
Date: Fri, 13 Jul 2007 17:55:35 +0900
Subject: [ANNOUNCE] Kexec for Xen on IA64 (v20070713)
Message-ID: <20070713085533.GA16653@verge.net.au>

Hi,

I'm happy to announce the another alpha release of Kexec for Xen on IA64.
The major changes are:

* SMP kexec now works!!! <-- this was a real pain
* The serial port now works in the second kernel on HP rx2620 hardware

I have trimed down the problems file, removing issues that have been
resolved, and happily it is now of a much more managable size.

http://www.vergenet.net/linux/kexec/ia64-xen.shtml
http://www.vergenet.net/linux/kexec/ia64-xen/20070713/xen-ia64-kexec-20070713.tar.bz2
http://www.vergenet.net/linux/kexec/ia64-xen/20070713/broken_out/README
http://www.vergenet.net/linux/kexec/ia64-xen/20070713/broken_out/BUILD
http://www.vergenet.net/linux/kexec/ia64-xen/20070713/broken_out/PROBLEMS


-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/



From oomichi at mxs.nes.nec.co.jp  Fri Jul 13 07:05:33 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Fri, 13 Jul 2007 20:05:33 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
Message-ID: <20070713200533oomichi@mail.jp.nec.com>


Hi all,

2007/07/10 08:02:43 -0400, Neil Horman <nhorman at redhat.com> wrote:
>> Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
>> In the kernel building process, distributors need to make CONFIGFILE
>> on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
>> may be an older kernel. So OSRELEASE should be modified to the building
>> kernel version by hand, but it is not smart.
>> 
>> To solve this problem, I'm proposing 2 plans.
>> Could you give me your opinion ?
>> 
>> Plan 1:
>>   A new option [--osrelease="string"] is added.
>>   The OSRELEASE of CONFIGFILE is overwritten by "string".
>>   In the kernel building process, distributors should specify "string"
>>   as the building kernel version.
>> 
>> Plan2:
>>   Remove the OSRELEASE from CONFIGFILE.
>>   Instead of checking the OSRELEASE, makedumpfile only checks whether the
>>   area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
>>   is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
>>   "system_utsname" must not point to the correct area in most cases.
>>   Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
>>   But I think there are not any problems because old makedumpfile will not
>>   read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
>>   the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
>>   will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
>>   should be updated with CONFIGFILE.
>> 
>> 
>> I'd like to change the name of CONFIGFILE to mkdfinfo.
>> 
>Why not, instead of either plan above, just redefine OSRELEASE to be the version
>of the kernel the config file was built against?  i.e. when you build a config
>file, you need to specify a kernel to extract symbol information from, why not
>grab the utsname from that kernel and use that to set OSRELEASE?  When you're
>building a config file the running kernel on the system isn't really relevent
>anyway.

Did you say "makedumpfile should get OSRELEASE from a vmlinux file,
and output it to a mkdfinfo file", right ?
If so, you are right. I'm creating the patch for it.

BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to consider
2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
from a mkdfinfo file.

In current implementation, makedumpfile considers 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE if a vmlinux file is specified instead of a
mkdfinfo file. On the other hand, makedumpfile can get 1st-kernel
PAGESIZE correctly if a mkdfinfo file is specified, because there
is the rule that a mkdfinfo file should be generated on 1st-kernel.

Now, I will change this rule for generating a mkdfinfo file on the
kernel-building environment. I feel considering 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE is better than considering the PAGESIZE of
kernel-building environment, because 1st-kernel and 2nd-kernel have
the same PAGESIZE in most cases such as relocatable kernel.


Please let me know your opinion.


Thanks
Ken'ichi Ohmichi


From bwalle at suse.de  Fri Jul 13 09:15:50 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Fri, 13 Jul 2007 15:15:50 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070713200533oomichi@mail.jp.nec.com>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
Message-ID: <20070713131550.GB10985@suse.de>

* Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-13 13:05]:
> 
> BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> While 2nd-kernel is running, new makedumpfile comes to consider
> 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> from a mkdfinfo file.

I don't think that's a good idea. IMO the kernel should be modified to
export the page size in a variable for that purpose. That would solve
all problems and dependencies, doesn't it?



Thanks,
   Bernhard


From ying.huang at intel.com  Fri Jul 13 19:15:25 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Fri, 13 Jul 2007 23:15:25 +0000
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
	<m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
Message-ID: <1184368525.1069.68.camel@caritas-dev.intel.com>

On Thu, 2007-07-12 at 10:32 -0600, Eric W. Biederman wrote:
> >
> > 1. Separate device suspend from device hibernate.
> 
> Actually in some very practical sense we already have two copies of
> this in the kernel.  device_shutdown and the hotunplug/module
> remove code.  So it is should be mostly a matter of using what we have.

Maybe I misuse the terminology. The "device hibernate" here means put
device into quiescent state and save the device state into memory for
later restore.

But, how to restore device state after jumping back from kexeced kernel
if device_shutdown or hotplug/module removing code is used?

> Basically all this entails is to modify sys_reboot()
> and adding a LINUX_REBOOT_CMD_KSPAWN and have that command
> enter the kexec path with the appropriate set of calls.
> I would be really surprised if this winds up with much
> more code then the current kernel_kexec function.

Yes, this is the right place to trigger kexec jump. Thank you for your
valuable comments. It seems that just the device state
quiesce/save/restore and CPU state save/restore code need to be added.

> This might wind up exactly the same as the current
> LINUX_REBOOT_CMD_KEXEC but at least until we have a working
> prototype it makes sense to allow for differences.
> 
> This should allow the kexec based implementation to coincide
> with the existing software suspend to disk code until it is proven out
> and then we can just remove all of the software suspend code to
> disk code.
> 
> > 2. Do not reserve memory for kexec kernel. That is, backup needed memory
> > before kexec and restore them after kexec.
> > 3. Support the in-place kexec? The relocatable kernel is not necessary
> > if this can be implemented.
> 
> It sounds like what you really want is the normal kexec path enhanced
> so that you can return to the kernel you started with.

Yes

> The normal kexec path already knows how to do the memory shuffle so
> it can do on demand memory allocation.  That code just needs to
> enhanced slightly so that you allocate an extra page, setup an inverse
> scatter gather list for restoring the pages, and teach relocate_kernel.S
> to preserve it's destination pages by using the inverse scatter gather
> list.

Yes, I have seen that code. The framework of current kexec memory
copying can be used for memory backup before kexec.

> The normal kexec path already calls device_shutdown and the like to
> stop devices from running.  Although again that code path is not
> prepared to restore the devices.

Yes, the device state quiesce/save/restore and CPU state save/restore
code should be added.

> For prototyping I would:
> - reserve a chunk of memory (possibly with the crashkernel= option)
>   and run a relocatable kernel out of it.  
> 
>   By using the normal kexec you can boot a relocatable restore kernel
>   in that reserved region. It is an extra step but it makes things
>   work today.
> 
> - I would use the normal sys_kexec_load.
> 
> - I would debug/tweak the user space and the code to reenter the
>   old kernel.  I.e. the device driver stop/start code.

The above 3 steps are exactly what I have done in this patch. I reserve
memory with crashkernel=, use sys_kexec_load (kexec -p ...) to load the
kexec kernel and manage to jump back to normal kernel. But I should not
mix the kexec jump trigger code with the software suspend code, that is,
use "kexec -e", not "echo disk > /sys/power/state".

>   Once it was basically working I would the update normal kexec
>   memory copy code in relocate.S to preserve the destination pages.

This is what I plan to do.

> > 4. Image writing/reading. (Only user space application is needed).
> 
> And possibly a few fixes to /dev/mem.  This is pretty much the same
> process as generating a core dump so there should be some synergy with that.
> 
> We probably want to use something like the ELF header the crashdump
> path uses to communicate to the kernel saving memory which memory
> regions need to be saved.  Which probably means that we you can use the
> exact same method as the kexec on panic kernel uses to save memory.

This sound good. The information in ELF header can be used to locate
necessary information for image writing.

> > 5. A smooth resume process. Maybe it is not needed to kexec a new kernel
> > for resume. For example, in the first stage of kernel boot, just first
> > 16M (or a little more) RAM is used, if the resume image is found, the
> > saved kernel image is resumed; if the resume image is not found, turn on
> > the remaining RAM. This will depends on 3.
> 
> Well I expect the resume will be load the resumed kernel into reserved
> memory.  And kexec a very small assembly stub that will jump back
> to the code in relocate_kernel.S which will call ret.
> 
> Then either hot add the rest of our memory or kexec to a kernel without
> restrictions.

Why a assembly stub is necessary? Is it not sufficient that just
continue to complete a normal boot (hot add the reset of memory) or load
the hibernated kernel (hibernated image) and jump to it?

> > 6. Reduce the boot-up time of kexec kernel. Maybe the kexec kernel can
> > be hibernate/resume by the normal kernel too. This way, a real
> > kexec/boot-up is only needed for the first time.
> 
> Well just not loading drivers you aren't going to use and generally avoiding
> long disk probing times will help here.  We control all of the code so
> it should be relatively straight forward.

Just not loading unnecessary drivers may be sufficient. But further
optimization is also possible.

The basic idea of optimization is:

For first run:

1. boot the normal kernel A
2. kexec the hibernate kernel B
3. jump back to kernel A
4. Save the kernel B into a image
5. Work under kernel A.

For normal use:

1. boot the normal kernel A
2. resume the image of kernel B
3. jump to kernel B
4. Save the kernel A into image

Best Regards,
Huang Ying


From ebiederm at xmission.com  Fri Jul 13 12:43:03 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 13 Jul 2007 10:43:03 -0600
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <1184368525.1069.68.camel@caritas-dev.intel.com> (Ying Huang's
	message of "Fri, 13 Jul 2007 23:15:25 +0000")
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
	<m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
	<1184368525.1069.68.camel@caritas-dev.intel.com>
Message-ID: <m1k5t4dzl4.fsf@ebiederm.dsl.xmission.com>

"Huang, Ying" <ying.huang at intel.com> writes:

> On Thu, 2007-07-12 at 10:32 -0600, Eric W. Biederman wrote:
>> >
>> > 1. Separate device suspend from device hibernate.
>> 
>> Actually in some very practical sense we already have two copies of
>> this in the kernel.  device_shutdown and the hotunplug/module
>> remove code.  So it is should be mostly a matter of using what we have.
>
> Maybe I misuse the terminology. The "device hibernate" here means put
> device into quiescent state and save the device state into memory for
> later restore.
>
> But, how to restore device state after jumping back from kexeced kernel
> if device_shutdown or hotplug/module removing code is used?

With device_shutdown there really isn't a path (although putting
the device into a quiescent state is exactly what that method does).

However with the module remove path you disassociate the pci device
and the pci device driver and then after restore you go through
the pci devices and you redo the association (as if the pci
device or the module had just been loaded).

For devices that have a really slow probe/initialization this might be
an issue but it will work, and generally it will work fairly quickly.

So in that sense restore may be the wrong concept for devices.
At least for prototypes.

>> Basically all this entails is to modify sys_reboot()
>> and adding a LINUX_REBOOT_CMD_KSPAWN and have that command
>> enter the kexec path with the appropriate set of calls.
>> I would be really surprised if this winds up with much
>> more code then the current kernel_kexec function.
>
> Yes, this is the right place to trigger kexec jump. Thank you for your
> valuable comments. It seems that just the device state
> quiesce/save/restore and CPU state save/restore code need to be
> added.

Yes.

For cpu state I'm fairly certain we don't need to do anything fancy.

At least for the first pass prototyping with a uniprocessor kernel
will remove that hurdle.


>> For prototyping I would:
>> - reserve a chunk of memory (possibly with the crashkernel= option)
>>   and run a relocatable kernel out of it.  
>> 
>>   By using the normal kexec you can boot a relocatable restore kernel
>>   in that reserved region. It is an extra step but it makes things
>>   work today.
>> 
>> - I would use the normal sys_kexec_load.
>> 
>> - I would debug/tweak the user space and the code to reenter the
>>   old kernel.  I.e. the device driver stop/start code.
>
> The above 3 steps are exactly what I have done in this patch. I reserve
> memory with crashkernel=, use sys_kexec_load (kexec -p ...) to load the
> kexec kernel and manage to jump back to normal kernel. But I should not
> mix the kexec jump trigger code with the software suspend code, that is,
> use "kexec -e", not "echo disk > /sys/power/state".

Right.  That caused all kinds of weirdness in your patch.


>> > 5. A smooth resume process. Maybe it is not needed to kexec a new kernel
>> > for resume. For example, in the first stage of kernel boot, just first
>> > 16M (or a little more) RAM is used, if the resume image is found, the
>> > saved kernel image is resumed; if the resume image is not found, turn on
>> > the remaining RAM. This will depends on 3.
>> 
>> Well I expect the resume will be load the resumed kernel into reserved
>> memory.  And kexec a very small assembly stub that will jump back
>> to the code in relocate_kernel.S which will call ret.
>> 
>> Then either hot add the rest of our memory or kexec to a kernel without
>> restrictions.
>
> Why a assembly stub is necessary? Is it not sufficient that just
> continue to complete a normal boot (hot add the reset of memory) or load
> the hibernated kernel (hibernated image) and jump to it?

I was thinking the assembly stub would be the small piece that jumps
to loaded hibernated kernel.  Quite possibly we could just get away
with providing no memory and just an entry point to kexec but it
makes sense to me to plan on running a couple of instructions.

Actually the way the kexec infrastructure it might be reasonable to
just use sys_kexec_load to load the entire hibernated image.  Except
for the fact that sys_kexec_load requires the source pages to be
in the processes memory image the code shouldn't have the 50% of
memory limitation already.

If we can get that going we don't even need to restrict the first
kernels memory.  So it might just require teaching sys_kexec_load
how to steal process pages.  Anyway something to think about.

>> Well just not loading drivers you aren't going to use and generally avoiding
>> long disk probing times will help here.  We control all of the code so
>> it should be relatively straight forward.
>
> Just not loading unnecessary drivers may be sufficient. But further
> optimization is also possible.
>
> The basic idea of optimization is:
>
> For first run:
>
> 1. boot the normal kernel A
> 2. kexec the hibernate kernel B
> 3. jump back to kernel A
> 4. Save the kernel B into a image
> 5. Work under kernel A.
>
> For normal use:
>
> 1. boot the normal kernel A
> 2. resume the image of kernel B
> 3. jump to kernel B
> 4. Save the kernel A into image

Yes.  That may help.  Cooperative multitasking between kernels.

Anyway all of that comes after we get something simple working.
Then we can see what really needs to be optimized, and what works
well enough.

Eric


From ying.huang at intel.com  Sat Jul 14 01:48:49 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Sat, 14 Jul 2007 13:48:49 +0800
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <m1k5t4dzl4.fsf@ebiederm.dsl.xmission.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<20070711172243.ab44c4d4.akpm@linux-foundation.org>
	<1184251423.9346.55.camel@caritas-dev.intel.com>
	<m14pk9fuqa.fsf@ebiederm.dsl.xmission.com>
	<1184368525.1069.68.camel@caritas-dev.intel.com>
	<m1k5t4dzl4.fsf@ebiederm.dsl.xmission.com>
Message-ID: <1184392129.1898.69.camel@caritas-dev.intel.com>

On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > Why a assembly stub is necessary? Is it not sufficient that just
> > continue to complete a normal boot (hot add the reset of memory) or load
> > the hibernated kernel (hibernated image) and jump to it?
> 
> I was thinking the assembly stub would be the small piece that jumps
> to loaded hibernated kernel.  Quite possibly we could just get away
> with providing no memory and just an entry point to kexec but it
> makes sense to me to plan on running a couple of instructions.

Oh, I got it. In my patch, there is such assembly stub in
arch/i386/kernel/kexec_jump.S. I think it is needed to restore basic CPU
state and accommodate some position independent restore code (such as
memory restore code).

> Actually the way the kexec infrastructure it might be reasonable to
> just use sys_kexec_load to load the entire hibernated image.  Except
> for the fact that sys_kexec_load requires the source pages to be
> in the processes memory image the code shouldn't have the 50% of
> memory limitation already.
> 
> If we can get that going we don't even need to restrict the first
> kernels memory.  So it might just require teaching sys_kexec_load
> how to steal process pages.  Anyway something to think about.

As for memory backupping and restoring during hibernating and resuming,
I think a possible picture can be as follow:

Memory:

  Total memory: 512M
  Memory used by hibernating/resuming kernel: 0~16M


Hibernating process:

  1. Normal kernel running
  2. Hibernating is triggered, sys_kexec_load is used to load
     hibernating kernel and initramfs into memory. Then
     sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
  3. In sys_reboot, kexec_jump is called to save device/CPU state,
     then relocate_kernel is called. kexec_jump and relocate_kernel
     reside in individual page in 16M~512M.
  4. In relocate_kernel, 0~16M is backupped firstly, then the
     hibernating kernel and initramfs is copied to 0~16M, after that,
     the hibernating kernel is booted.
  5. In hibernating kernel, the memory of normal kernel (it is in
     16M~512M) is saved into a hibernation image through /dev/mem
     and ELF header.


Resume process:

  1. Resuming kernel is booted as a normal kernel, but the memory is
     restricted to 0~16M.
  2. Checking whether there is a effective hibernation image. If
     there isn't, the memory of 16M~512M is hot added, and the normal
     boot up process continues; If there is, a resuming process is
     triggered.
  3. sys_kexec_load is used to restore the memory state of hibernated
     kernel. The sys_kexec_load works in crashdump way, that is, the
     hibernation image is copied to destination location in 16M~512M
     in sys_kexec_load instead of relocate_kernel. There is no half
     of memory size restriction.
  4. sys_reboot is called to trigger jumping back, which will jump back
     to kexec_jump of hibernated kernel.
  5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
     back from the backup area in 16M~512M. The memory state of
     hibernated kernel is restored totally. The CPU and device state
     can be restored after that.


If there is too much difficulty to hot add memory in step 2. A more
conservative method can be used as step 1 and step 2.

  1. A normal kernel is booted.
  2. Checking whether there is a effective hibernation image. If there
     isn't, continue the normal boot process; otherwise, a resuming
     kernel is kexeced in memory 0~16M. The resuming process will
     continue in kexeced resuming kernel.

Best Regards,
Huang Ying


From rjw at sisk.pl  Sat Jul 14 05:59:46 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Sat, 14 Jul 2007 11:59:46 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <1184392129.1898.69.camel@caritas-dev.intel.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<m1k5t4dzl4.fsf@ebiederm.dsl.xmission.com>
	<1184392129.1898.69.camel@caritas-dev.intel.com>
Message-ID: <200707141159.47289.rjw@sisk.pl>

On Saturday, 14 July 2007 07:48, Huang, Ying wrote:
> On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > > Why a assembly stub is necessary? Is it not sufficient that just
> > > continue to complete a normal boot (hot add the reset of memory) or load
> > > the hibernated kernel (hibernated image) and jump to it?
> > 
> > I was thinking the assembly stub would be the small piece that jumps
> > to loaded hibernated kernel.  Quite possibly we could just get away
> > with providing no memory and just an entry point to kexec but it
> > makes sense to me to plan on running a couple of instructions.
> 
> Oh, I got it. In my patch, there is such assembly stub in
> arch/i386/kernel/kexec_jump.S. I think it is needed to restore basic CPU
> state and accommodate some position independent restore code (such as
> memory restore code).
> 
> > Actually the way the kexec infrastructure it might be reasonable to
> > just use sys_kexec_load to load the entire hibernated image.  Except
> > for the fact that sys_kexec_load requires the source pages to be
> > in the processes memory image the code shouldn't have the 50% of
> > memory limitation already.
> > 
> > If we can get that going we don't even need to restrict the first
> > kernels memory.  So it might just require teaching sys_kexec_load
> > how to steal process pages.  Anyway something to think about.
> 
> As for memory backupping and restoring during hibernating and resuming,
> I think a possible picture can be as follow:
> 
> Memory:
> 
>   Total memory: 512M
>   Memory used by hibernating/resuming kernel: 0~16M
> 
> 
> Hibernating process:
> 
>   1. Normal kernel running
>   2. Hibernating is triggered, sys_kexec_load is used to load
>      hibernating kernel and initramfs into memory. Then
>      sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
>   3. In sys_reboot, kexec_jump is called to save device/CPU state,
>      then relocate_kernel is called. kexec_jump and relocate_kernel
>      reside in individual page in 16M~512M.

OK

What's going to happen to devices at this point?

>   4. In relocate_kernel, 0~16M is backupped firstly, then the
>      hibernating kernel and initramfs is copied to 0~16M, after that,
>      the hibernating kernel is booted.
>   5. In hibernating kernel, the memory of normal kernel (it is in
>      16M~512M) is saved into a hibernation image through /dev/mem
>      and ELF header.

I don't think it can be _that_ simple:
(a) what about processes' memory
(b) what about areas that shouldn't be saved?

> Resume process:
> 
>   1. Resuming kernel is booted as a normal kernel, but the memory is
>      restricted to 0~16M.
>   2. Checking whether there is a effective hibernation image. If
>      there isn't, the memory of 16M~512M is hot added, and the normal
>      boot up process continues; If there is, a resuming process is
>      triggered.
>   3. sys_kexec_load is used to restore the memory state of hibernated
>      kernel. The sys_kexec_load works in crashdump way, that is, the
>      hibernation image is copied to destination location in 16M~512M
>      in sys_kexec_load instead of relocate_kernel. There is no half
>      of memory size restriction.
>   4. sys_reboot is called to trigger jumping back, which will jump back
>      to kexec_jump of hibernated kernel.
>   5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
>      back from the backup area in 16M~512M. The memory state of
>      hibernated kernel is restored totally. The CPU and device state
>      can be restored after that.

Well, I don't know why this needs to be that complicated.  We already have
code in the mainline that's able to load a large hibernation image into memory
and jump to the kernel being restored.  And it has _no_ 50% of RAM limitation,
this is the _saving_ part of the current code that this limitation comes from.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From ying.huang at intel.com  Sat Jul 14 06:55:54 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Sat, 14 Jul 2007 18:55:54 +0800
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <200707141159.47289.rjw@sisk.pl>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<m1k5t4dzl4.fsf@ebiederm.dsl.xmission.com>
	<1184392129.1898.69.camel@caritas-dev.intel.com>
	<200707141159.47289.rjw@sisk.pl>
Message-ID: <1184410554.1898.84.camel@caritas-dev.intel.com>

On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > Hibernating process:
> > 
> >   1. Normal kernel running
> >   2. Hibernating is triggered, sys_kexec_load is used to load
> >      hibernating kernel and initramfs into memory. Then
> >      sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
> >   3. In sys_reboot, kexec_jump is called to save device/CPU state,
> >      then relocate_kernel is called. kexec_jump and relocate_kernel
> >      reside in individual page in 16M~512M.
> 
> OK
> What's going to happen to devices at this point?
> 

The devices should be quiesced and the state of devices should be saved
in kexec_jump, before relocate_kernel is called. This needs the
implementation of device hibernating as you mentioned before.

> >   4. In relocate_kernel, 0~16M is backupped firstly, then the
> >      hibernating kernel and initramfs is copied to 0~16M, after that,
> >      the hibernating kernel is booted.
> >   5. In hibernating kernel, the memory of normal kernel (it is in
> >      16M~512M) is saved into a hibernation image through /dev/mem
> >      and ELF header.
> 
> I don't think it can be _that_ simple:
> (a) what about processes' memory
> (b) what about areas that shouldn't be saved?

The mem_map (struct page[]) of every zone of hibernated kernel is
checked.  Necessary pages are saved, like memory snapshot of software
suspend, but in user space.

> > Resume process:
> > 
> >   1. Resuming kernel is booted as a normal kernel, but the memory is
> >      restricted to 0~16M.
> >   2. Checking whether there is a effective hibernation image. If
> >      there isn't, the memory of 16M~512M is hot added, and the normal
> >      boot up process continues; If there is, a resuming process is
> >      triggered.
> >   3. sys_kexec_load is used to restore the memory state of hibernated
> >      kernel. The sys_kexec_load works in crashdump way, that is, the
> >      hibernation image is copied to destination location in 16M~512M
> >      in sys_kexec_load instead of relocate_kernel. There is no half
> >      of memory size restriction.
> >   4. sys_reboot is called to trigger jumping back, which will jump back
> >      to kexec_jump of hibernated kernel.
> >   5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
> >      back from the backup area in 16M~512M. The memory state of
> >      hibernated kernel is restored totally. The CPU and device state
> >      can be restored after that.
> 
> Well, I don't know why this needs to be that complicated.  We already have
> code in the mainline that's able to load a large hibernation image into memory
> and jump to the kernel being restored.  And it has _no_ 50% of RAM limitation,
> this is the _saving_ part of the current code that this limitation comes from.

There is much similarity between sys_kexec_load and software resuming.
If resuming can be done by sys_kexec_load, then we need not two similar
functionality in kernel.

Best Regards,
Huang Ying


From rjw at sisk.pl  Sat Jul 14 15:16:09 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Sat, 14 Jul 2007 21:16:09 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <1184410554.1898.84.camel@caritas-dev.intel.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<200707141159.47289.rjw@sisk.pl>
	<1184410554.1898.84.camel@caritas-dev.intel.com>
Message-ID: <200707142116.10237.rjw@sisk.pl>

On Saturday, 14 July 2007 12:55, Huang, Ying wrote:
> On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > > Hibernating process:
> > > 
> > >   1. Normal kernel running
> > >   2. Hibernating is triggered, sys_kexec_load is used to load
> > >      hibernating kernel and initramfs into memory. Then
> > >      sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
> > >   3. In sys_reboot, kexec_jump is called to save device/CPU state,
> > >      then relocate_kernel is called. kexec_jump and relocate_kernel
> > >      reside in individual page in 16M~512M.
> > 
> > OK
> > What's going to happen to devices at this point?
> > 
> 
> The devices should be quiesced and the state of devices should be saved
> in kexec_jump, before relocate_kernel is called. This needs the
> implementation of device hibernating as you mentioned before.

Hmm, at which point devices are normally shut down when kexec is used?

> > >   4. In relocate_kernel, 0~16M is backupped firstly, then the
> > >      hibernating kernel and initramfs is copied to 0~16M, after that,
> > >      the hibernating kernel is booted.
> > >   5. In hibernating kernel, the memory of normal kernel (it is in
> > >      16M~512M) is saved into a hibernation image through /dev/mem
> > >      and ELF header.
> > 
> > I don't think it can be _that_ simple:
> > (a) what about processes' memory
> > (b) what about areas that shouldn't be saved?
> 
> The mem_map (struct page[]) of every zone of hibernated kernel is
> checked.  Necessary pages are saved, like memory snapshot of software
> suspend, but in user space.

Well, it's not enough to check that, sorry.  That's why we have
register_nosave_region().

> > > Resume process:
> > > 
> > >   1. Resuming kernel is booted as a normal kernel, but the memory is
> > >      restricted to 0~16M.
> > >   2. Checking whether there is a effective hibernation image. If
> > >      there isn't, the memory of 16M~512M is hot added, and the normal
> > >      boot up process continues; If there is, a resuming process is
> > >      triggered.
> > >   3. sys_kexec_load is used to restore the memory state of hibernated
> > >      kernel. The sys_kexec_load works in crashdump way, that is, the
> > >      hibernation image is copied to destination location in 16M~512M
> > >      in sys_kexec_load instead of relocate_kernel. There is no half
> > >      of memory size restriction.
> > >   4. sys_reboot is called to trigger jumping back, which will jump back
> > >      to kexec_jump of hibernated kernel.
> > >   5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
> > >      back from the backup area in 16M~512M. The memory state of
> > >      hibernated kernel is restored totally. The CPU and device state
> > >      can be restored after that.
> > 
> > Well, I don't know why this needs to be that complicated.  We already have
> > code in the mainline that's able to load a large hibernation image into memory
> > and jump to the kernel being restored.  And it has _no_ 50% of RAM limitation,
> > this is the _saving_ part of the current code that this limitation comes from.
> 
> There is much similarity between sys_kexec_load and software resuming.
> If resuming can be done by sys_kexec_load, then we need not two similar
> functionality in kernel.

Oh, I see, but your proposed solution seems to be more complicated than that.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From ying.huang at intel.com  Sun Jul 15 05:30:04 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Sun, 15 Jul 2007 17:30:04 +0800
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <200707142116.10237.rjw@sisk.pl>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<200707141159.47289.rjw@sisk.pl>
	<1184410554.1898.84.camel@caritas-dev.intel.com>
	<200707142116.10237.rjw@sisk.pl>
Message-ID: <1184491804.1898.121.camel@caritas-dev.intel.com>

On Sat, 2007-07-14 at 21:16 +0200, Rafael J. Wysocki wrote:
> > The devices should be quiesced and the state of devices should be saved
> > in kexec_jump, before relocate_kernel is called. This needs the
> > implementation of device hibernating as you mentioned before.
> 
> Hmm, at which point devices are normally shut down when kexec is used?

I think putting devices in quiescent state (not in low power state) is
sufficient for booting a new kernel with kexec, is it? According to my
experiment, the new kernel can be booted with kexec if the .suspend
method the drivers is called before kexec (given CONFIG_ACPI is not
selected).

Do we need a device quiesce/save + device shutdown for kexeced kernel to
work? I don't think so.

> > > >   4. In relocate_kernel, 0~16M is backupped firstly, then the
> > > >      hibernating kernel and initramfs is copied to 0~16M, after that,
> > > >      the hibernating kernel is booted.
> > > >   5. In hibernating kernel, the memory of normal kernel (it is in
> > > >      16M~512M) is saved into a hibernation image through /dev/mem
> > > >      and ELF header.
> > > 
> > > I don't think it can be _that_ simple:
> > > (a) what about processes' memory
> > > (b) what about areas that shouldn't be saved?
> > 
> > The mem_map (struct page[]) of every zone of hibernated kernel is
> > checked.  Necessary pages are saved, like memory snapshot of software
> > suspend, but in user space.
> 
> Well, it's not enough to check that, sorry.  That's why we have
> register_nosave_region().

After some investigation, I found the usage of "nosave" is as follow on
i386:

1. __nosavedata
   used only for global variable in_suspend and swsusp_pg_dir
2. PG_nosave page flags
   used for snapshot itself

Both are not necessary for kexec based hibernation. Because the image
are written from a different kernel, the memory of hibernating kernel
will not be saved, they can be used freely during image writing/reading.

On x86_64, there is another usage of nosave during processing E820
memory map. But I don't know why the memory region other than E820_RAM
are marked as nosave. I think only the memory region of type E820_RAM
will be thought of normal memory, others will be thought as reserved. Is
it sufficient just to check whether the page is reserved?
 
Best Regards,
Huang Ying


From rjw at sisk.pl  Sun Jul 15 06:49:25 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Sun, 15 Jul 2007 12:49:25 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <1184491804.1898.121.camel@caritas-dev.intel.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<200707142116.10237.rjw@sisk.pl>
	<1184491804.1898.121.camel@caritas-dev.intel.com>
Message-ID: <200707151249.26148.rjw@sisk.pl>

On Sunday, 15 July 2007 11:30, Huang, Ying wrote:
> On Sat, 2007-07-14 at 21:16 +0200, Rafael J. Wysocki wrote:
> > > The devices should be quiesced and the state of devices should be saved
> > > in kexec_jump, before relocate_kernel is called. This needs the
> > > implementation of device hibernating as you mentioned before.
> > 
> > Hmm, at which point devices are normally shut down when kexec is used?
> 
> I think putting devices in quiescent state (not in low power state) is
> sufficient for booting a new kernel with kexec, is it? According to my
> experiment, the new kernel can be booted with kexec if the .suspend
> method the drivers is called before kexec (given CONFIG_ACPI is not
> selected).

Well, this illustrates the problem.  With ACPI, the devices are suspended
and without it their kind of quiesced.

Generally, we need to make them be quiesced with or without ACPI.  IOW,
the per-driver callbacks used before hibernation should be different from those
used before the suspend (to RAM and similar).
 
> Do we need a device quiesce/save + device shutdown for kexeced kernel to
> work? I don't think so.

No, we don't.

Still, my question was related to how kexec _normally_ handles devices.  Are
they shut down or they are just left in the state in which they were before?

I assume that kexec loads a new kernel into memory and then passes control
to it, but I think the new kernel needs to set up devices for itself.  I assume
that this is done in a usual way, ie. devices are detected, registered,
initialized, etc.  So, my question is if kexec prepares devices for that in any
way.

> > > > >   4. In relocate_kernel, 0~16M is backupped firstly, then the
> > > > >      hibernating kernel and initramfs is copied to 0~16M, after that,
> > > > >      the hibernating kernel is booted.
> > > > >   5. In hibernating kernel, the memory of normal kernel (it is in
> > > > >      16M~512M) is saved into a hibernation image through /dev/mem
> > > > >      and ELF header.
> > > > 
> > > > I don't think it can be _that_ simple:
> > > > (a) what about processes' memory
> > > > (b) what about areas that shouldn't be saved?
> > > 
> > > The mem_map (struct page[]) of every zone of hibernated kernel is
> > > checked.  Necessary pages are saved, like memory snapshot of software
> > > suspend, but in user space.
> > 
> > Well, it's not enough to check that, sorry.  That's why we have
> > register_nosave_region().
> 
> After some investigation, I found the usage of "nosave" is as follow on
> i386:
> 
> 1. __nosavedata
>    used only for global variable in_suspend and swsusp_pg_dir
> 2. PG_nosave page flags
>    used for snapshot itself

We don't use PG_nosave flags any more at all.

> Both are not necessary for kexec based hibernation. Because the image
> are written from a different kernel, the memory of hibernating kernel
> will not be saved, they can be used freely during image writing/reading.

This is not the point.  There are memory regions that you should not _restore_,
because that will cause harm.

> On x86_64, there is another usage of nosave during processing E820
> memory map. But I don't know why the memory region other than E820_RAM
> are marked as nosave. I think only the memory region of type E820_RAM
> will be thought of normal memory, others will be thought as reserved. Is
> it sufficient just to check whether the page is reserved?

No, it's not.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From ying.huang at intel.com  Sun Jul 15 03:13:13 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Sun, 15 Jul 2007 15:13:13 +0800
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
Message-ID: <1184483593.1898.98.camel@caritas-dev.intel.com>

The changelog between v1 and v2

1. The kexec jump implementation is put into the kexec/kdump
   framework instead of software suspend framework. The device
   and CPU state save/restore code of software suspend is called
   when needed.

2. The same code path is used for both kexec a new kernel and jump
   back to original kernel.

The complete changelog of the patch is as follow:

---

Kexec base hibernation has some potential advantages over uswsusp and
TuxOnIce (suspend2). Some most obvious advantages are:

1. The hibernation image size can exceed half of memory size easily.
2. The hibernation image can be written to and read from almost
   anywhere, such as USB disk, NFS.

This patch implements the functionality of "jumping from kexeced
kernel to original kernel". That is, the following sequence is
possible:

1. Boot a kernel A
2. Work under kernel A
3. Kexec another kernel B in kernel A
4. Work under kernel B
5. Jump from kernel B to kernel A
6. Continue work under kernel A

This is the first step to implement kexec based hibernation. If the
memory image of kernel A is written to or read from a permanent media
in step 4, a preliminary version of kexec based hibernation can be
implemented.

The kernel B run as a crashdump kernel in reserved memory region. This
is the biggest constrains of the patch. It is planed to be eliminated
in the future version. That is, instead of reserving memory region
previously, the needed memory region is backupped before kexec and
restored after jumping back.

Another constrains of the patch is that the CONFIG_ACPI must be turned
off to make kexec jump work. Because ACPI will put devices into low
power state, the kexeced kernel can not be booted properly under
it. This constrains can be eliminated by separating the suspend method
and hibernate method of the devices as proposed earlier in the LKML.

The kexec jump is implemented in the framework of kexec/kdump. In
sys_reboot, a new command named LINUX_REBOOT_CMD_KJUMP is defined to
trigger the jumping to (executing) the new kernel or jump back to the
original kernel.

Now, only the i386 architecture is supported. The patch is based on
Linux kernel 2.6.22, and has been tested on my IBM T42.

Usage:

1. Compile kernel with following options selected:

CONFIG_X86_32=y
CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
CONFIG_KEXEC=y
CONFIG_PM=y
CONFIG_KEXEC_JUMP=y

2. Compile the kexec-tools with kdump and kjump patches, the
   kdump patch can be found at:

http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump10.patch

   While, the kexec-tools kjump patch is appended with the mail.

3. Boot kernel compiled for normal usage, the reserved crash kernel
   memory region must be added to kernel command line as following:

   crashkernel=<XX>M@<XX>M

   Where, <XX> should be replaced by the real memory size and position.

4. Load kernel compiled for hibernating usage as a crashdump kernel
   with kexec, the same kernel as that of 3 can be used if
   CONFIG_RELOCATABLE=y is selected. The kernel command line option as
   following must be appended to kernel command line.

   kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`

   For example, the shell command line can be as follow:

   kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal
       kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"

5. Boot the hibernating kernel with following shell command line:

   kexec -j

6. In the kexec booted kernel, trigger the jumping back with following
   shell command.

   kexec -j

---

changelog of kexec-tools

A new command line option -j/--jump is added to support
jumping/executing the currently loaded kernel or jumping back to the
original kernel. The implementation of -j/--jump is to call
corresponding syscall.

For i386 architecture, the address of backup of 0~640k is passed to
kexeced kernel as a kernel command line option. This is used by
kexeced kernel to restore the backup.

---

Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
===================================================================
--- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c	2007-07-08 23:00:25.000000000 +0800
+++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c	2007-07-14 17:06:45.000000000 +0800
@@ -428,6 +428,29 @@
 	return 0;
 }
 
+/* Adds the kexec_backup= command line parameter to command line. */
+static int cmdline_add_backup(char *cmdline, unsigned long addr)
+{
+	int cmdlen, len, align = 1024;
+	char str[30], *ptr;
+
+	/* Passing in kexec_backup=xxxK format. Saves space required
+	 * in cmdline. Ensure 1K alignment*/
+	if (addr%align)
+		return -1;
+	addr = addr/align;
+	ptr = str;
+	strcpy(str, " kexec_backup=");
+	ptr += strlen(str);
+	ultoa(addr, ptr);
+	strcat(str, "K");
+	len = strlen(str);
+	cmdlen = strlen(cmdline) + len;
+	if (cmdlen > (COMMAND_LINE_SIZE - 1))
+		die("Command line overflow\n");
+	strcat(cmdline, str);
+	return 0;
+}
 
 /*
  * This routine is specific to i386 architecture to maintain the
@@ -724,5 +747,6 @@
 		return -1;
 	cmdline_add_memmap(mod_cmdline, memmap_p);
 	cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
+	cmdline_add_backup(mod_cmdline, info->backup_start);
 	return 0;
 }
Index: kexec-tools-1.101/kexec/kexec-syscall.h
===================================================================
--- kexec-tools-1.101.orig/kexec/kexec-syscall.h	2007-07-14 17:24:52.000000000 +0800
+++ kexec-tools-1.101/kexec/kexec-syscall.h	2007-07-14 17:27:10.000000000 +0800
@@ -21,6 +21,7 @@
 #define LINUX_REBOOT_CMD_KEXEC_OLD	0x81726354
 #define LINUX_REBOOT_CMD_KEXEC_OLD2	0x18263645
 #define LINUX_REBOOT_CMD_KEXEC		0x45584543
+#define LINUX_REBOOT_CMD_KJUMP		0x3928A5FD
 
 #ifdef __i386__
 #define __NR_kexec_load		283
@@ -60,6 +61,10 @@
 	return (long) syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC, 0);
 }
 
+static inline long kexec_jump(void)
+{
+	return (long) syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KJUMP, 0);
+}
 
 #define KEXEC_ON_CRASH  0x00000001
 #define KEXEC_ARCH_MASK 0xffff0000
Index: kexec-tools-1.101/kexec/kexec.c
===================================================================
--- kexec-tools-1.101.orig/kexec/kexec.c	2007-07-14 16:57:26.000000000 +0800
+++ kexec-tools-1.101/kexec/kexec.c	2007-07-14 21:04:51.000000000 +0800
@@ -660,6 +660,17 @@
 	return -1;
 }
 
+/*
+ *	Jump to the new kernel
+ */
+static int my_jump(void)
+{
+	int result;
+
+	result = kexec_jump();
+	return result;
+}
+
 static void version(void)
 {
 	printf("kexec " VERSION " released " RELEASE_DATE "\n");
@@ -683,6 +694,7 @@
 		" -p, --load-panic     Load the new kernel for use on panic.\n"
 		" -u, --unload         Unload the current kexec target kernel.\n"
 		" -e, --exec           Execute a currently loaded kernel.\n"
+		" -j, --jump           Jump to a currently loaded kernel or jump back to the previous kernel.\n"
 		" -t, --type=TYPE      Specify the new kernel is of this type.\n"
 		"     --mem-min=<addr> Specify the lowest memory addres to load code into.\n"
 		"     --mem-max=<addr> Specify the highest memory addres to load code into.\n"
@@ -715,6 +727,7 @@
 {
 	int do_load = 1;
 	int do_exec = 0;
+	int do_jump = 0;
 	int do_shutdown = 1;
 	int do_sync = 1;
 	int do_ifdown = 0;
@@ -768,6 +781,14 @@
 			do_ifdown = 1;
 			do_exec = 1;
 			break;
+		case OPT_JUMP:
+			do_load = 0;
+			do_shutdown = 0;
+			do_sync = 1;
+			do_ifdown = 0;
+			do_exec = 0;
+			do_jump = 1;
+			break;
 		case OPT_TYPE:
 			type = optarg;
 			break;
@@ -833,6 +854,9 @@
 	if ((result == 0) && do_exec) {
 		result = my_exec();
 	}
+	if ((result == 0) && do_jump) {
+		result = my_jump();
+	}
 
 	fflush(stdout);
 	fflush(stderr);
Index: kexec-tools-1.101/kexec/kexec.h
===================================================================
--- kexec-tools-1.101.orig/kexec/kexec.h	2007-07-14 17:09:28.000000000 +0800
+++ kexec-tools-1.101/kexec/kexec.h	2007-07-14 17:10:43.000000000 +0800
@@ -151,6 +151,7 @@
 #define OPT_FORCE		'f'
 #define OPT_NOIFDOWN		'x'
 #define OPT_EXEC		'e'
+#define OPT_JUMP		'j'
 #define OPT_LOAD		'l'
 #define OPT_UNLOAD		'u'
 #define OPT_TYPE		't'
@@ -166,12 +167,13 @@
 	{ "load",		0, 0, OPT_LOAD }, \
 	{ "unload",		0, 0, OPT_UNLOAD }, \
 	{ "exec",		0, 0, OPT_EXEC }, \
+	{ "jump",		0, 0, OPT_JUMP }, \
 	{ "type",		1, 0, OPT_TYPE }, \
 	{ "load-panic",         0, 0, OPT_PANIC }, \
 	{ "mem-min",		1, 0, OPT_MEM_MIN }, \
 	{ "mem-max",		1, 0, OPT_MEM_MAX }, \
 
-#define KEXEC_OPT_STR "hvdfxluet:p"
+#define KEXEC_OPT_STR "hvdfxluejt:p"
 
 extern void die(char *fmt, ...);
 extern void *xmalloc(size_t size);


From ying.huang at intel.com  Sun Jul 15 03:13:59 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Sun, 15 Jul 2007 15:13:59 +0800
Subject: [PATH 1/1] Kexec jump - v2 - kexec jump
Message-ID: <1184483639.1898.99.camel@caritas-dev.intel.com>

This patch implement the functionality of jumping from kexeced kernel
to original kernel.

A new reboot command named LINUX_REBOOT_CMD_KJUMP is defined to
trigger the jumping to (executing) the new kernel or jumping back to
the original kernel.

To support jumping back from kexeced kernel, before executing the new
kernel, the devices are put into quiescent state (to be fully
implemented), and the state of devices and CPU is saved. After jumping
back from kexeced kernel, the state of devices and CPU are restored
accordingly. The devices/CPU state save/restore code of software
suspend is called to implement corresponding function.

Signed-off-by: Huang Ying <ying.huang at intel.com>

---

 arch/i386/Kconfig                |    7 +++
 arch/i386/kernel/Makefile        |    1 
 arch/i386/kernel/kexec_jump.S    |   74 +++++++++++++++++++++++++++++++++++++
 arch/i386/kernel/machine_kexec.c |   59 +++++++++++++++++++++++++++++
 include/asm-i386/kexec.h         |    4 ++
 include/linux/kexec.h            |   17 ++++++++
 include/linux/reboot.h           |    1 
 kernel/kexec.c                   |   78 +++++++++++++++++++++++++++++++++++++++
 kernel/ksysfs.c                  |   12 ++++++
 kernel/sys.c                     |    8 ++++
 10 files changed, 261 insertions(+)

Index: linux-2.6/arch/i386/kernel/Makefile
===================================================================
--- linux-2.6.orig/arch/i386/kernel/Makefile	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/arch/i386/kernel/Makefile	2007-07-14 17:50:50.000000000 +0800
@@ -27,6 +27,7 @@
 obj-$(CONFIG_X86_REBOOTFIXUPS)	+= reboot_fixups.o
 obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o crash.o
 obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
+obj-$(CONFIG_KEXEC_JUMP)	+= kexec_jump.o
 obj-$(CONFIG_X86_NUMAQ)		+= numaq.o
 obj-$(CONFIG_X86_SUMMIT_NUMA)	+= summit.o
 obj-$(CONFIG_KPROBES)		+= kprobes.o
Index: linux-2.6/arch/i386/kernel/machine_kexec.c
===================================================================
--- linux-2.6.orig/arch/i386/kernel/machine_kexec.c	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/arch/i386/kernel/machine_kexec.c	2007-07-15 11:22:23.000000000 +0800
@@ -10,6 +10,7 @@
 #include <linux/kexec.h>
 #include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/highmem.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/tlbflush.h>
@@ -169,3 +170,61 @@
 	return 0;
 }
 early_param("crashkernel", parse_crashkernel);
+
+#ifdef CONFIG_KEXEC_JUMP
+int machine_kexec_jump(void)
+{
+	asmlinkage int (*real_jump)(void *buf);
+	unsigned long jump_buf_pfn;
+	void *jump_buf;
+
+	if (!(kexec_flags & KEXEC_FLAGS_IS_KEXECED_KERNEL) &&
+	    !kexec_crash_image)
+		return -EINVAL;
+	jump_buf_pfn = kexec_get_jump_buf_pfn(0);
+	if (!jump_buf_pfn)
+		return -EINVAL;
+	jump_buf = kmap_atomic_pfn(jump_buf_pfn, KM_PTE0);
+	memcpy(jump_buf + PAGE_SIZE/2, machine_kexec_real_jump, PAGE_SIZE/2);
+	real_jump = jump_buf + PAGE_SIZE/2;
+
+	if (!real_jump(jump_buf))
+		machine_kexec(kexec_crash_image);
+	kunmap_atomic(jump_buf, KM_PTE0);
+	return 0;
+}
+
+static unsigned long kexec_backup_addr = ~0UL;
+
+/* kexec_backup= specifies the location of backuped 0~640k memory of
+ * crashed kernel.
+ */
+static int __init parse_kexec_backup(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	kexec_backup_addr = memparse(arg, &arg);
+	return 0;
+}
+early_param("kexec_backup", parse_kexec_backup);
+
+void kexec_restore_backup(void)
+{
+	void *vaddr;
+	void *vaddr_backup;
+	unsigned long paddr;
+
+	if (kexec_backup_addr == ~0UL)
+		return;
+
+	for (paddr = 0; paddr < 640 * 1024; paddr += PAGE_SIZE) {
+		vaddr = kmap_atomic_pfn(paddr >> PAGE_SHIFT, KM_PTE0);
+		vaddr_backup = kmap_atomic_pfn((paddr+kexec_backup_addr) >> PAGE_SHIFT,
+					       KM_PTE1);
+		memcpy(vaddr, vaddr_backup, PAGE_SIZE);
+		kunmap_atomic(vaddr, KM_PTE0);
+		kunmap_atomic(vaddr_backup, KM_PTE1);
+	}
+}
+#endif /* CONFIG_KEXEC_JUMP */
Index: linux-2.6/include/asm-i386/kexec.h
===================================================================
--- linux-2.6.orig/include/asm-i386/kexec.h	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/include/asm-i386/kexec.h	2007-07-14 21:21:16.000000000 +0800
@@ -94,6 +94,10 @@
 		unsigned long start_address,
 		unsigned int has_pae) ATTRIB_NORET;
 
+#ifdef CONFIG_KEXEC_JUMP
+extern asmlinkage int machine_kexec_real_jump(void *buf);
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _I386_KEXEC_H */
Index: linux-2.6/include/linux/kexec.h
===================================================================
--- linux-2.6.orig/include/linux/kexec.h	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/include/linux/kexec.h	2007-07-15 11:22:57.000000000 +0800
@@ -1,6 +1,11 @@
 #ifndef LINUX_KEXEC_H
 #define LINUX_KEXEC_H
 
+#ifdef CONFIG_KEXEC_JUMP
+#define KEXEC_FLAGS_IS_KEXECED_KERNEL     0x1
+#endif /* CONFIG_KEXEC_JUMP */
+
+#ifndef __ASSEMBLY__
 #ifdef CONFIG_KEXEC
 #include <linux/types.h>
 #include <linux/list.h>
@@ -161,4 +166,16 @@
 static inline void crash_kexec(struct pt_regs *regs) { }
 static inline int kexec_should_crash(struct task_struct *p) { return 0; }
 #endif /* CONFIG_KEXEC */
+
+#ifdef CONFIG_KEXEC_JUMP
+extern int kexec_flags;
+extern int machine_kexec_jump(void);
+extern int kexec_jump(void);
+extern unsigned long kexec_get_jump_buf_pfn(int alloc);
+extern void kexec_restore_backup(void);
+#else
+static inline int kexec_jump(void) { return 0; }
+#endif /* CONFIG_KEXEC_JUMP */
+#endif /* !__ASSEMBLY__ */
+
 #endif /* LINUX_KEXEC_H */
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/kernel/kexec.c	2007-07-15 12:57:25.000000000 +0800
@@ -22,6 +22,9 @@
 #include <linux/hardirq.h>
 #include <linux/elf.h>
 #include <linux/elfcore.h>
+#include <linux/suspend.h>
+#include <linux/pm.h>
+#include <linux/cpu.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>
@@ -1135,3 +1138,78 @@
 	return 0;
 }
 module_init(crash_notes_memory_init)
+
+#ifdef CONFIG_KEXEC_JUMP
+int kexec_flags;
+
+static unsigned long kexec_jump_buf_pfn;
+
+static int __init parse_kexec_jump_buf_pfn(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	kexec_jump_buf_pfn = memparse(arg, &arg);
+	kexec_flags |= KEXEC_FLAGS_IS_KEXECED_KERNEL;
+	return 0;
+}
+early_param("kexec_jump_buf_pfn", parse_kexec_jump_buf_pfn);
+
+unsigned long kexec_get_jump_buf_pfn(int alloc)
+{
+	struct page *jump_buf_page;
+
+	if (!kexec_jump_buf_pfn && alloc) {
+		jump_buf_page = alloc_page(GFP_KERNEL);
+		kexec_jump_buf_pfn = page_to_pfn(jump_buf_page);
+	}
+	return kexec_jump_buf_pfn;
+}
+
+int kexec_jump(void)
+{
+	int error;
+
+	if (!(kexec_flags & KEXEC_FLAGS_IS_KEXECED_KERNEL) &&
+	    !kexec_crash_image)
+		return -EINVAL;
+	error = device_suspend(PMSG_FREEZE);
+	if (error)
+		goto Resume_devices;
+	error = disable_nonboot_cpus();
+	if (error)
+		goto Enable_cpus;
+	local_irq_disable();
+	/* At this point, device_suspend() has been called, but *not*
+	 * device_power_down(). We *must* device_power_down() now.
+	 * Otherwise, drivers for some devices (e.g. interrupt controllers)
+	 * become desynchronized with the actual state of the hardware
+	 * at resume time, and evil weirdness ensues.
+	 */
+	error = device_power_down(PMSG_FREEZE);
+	if (error)
+		goto Enable_irqs;
+
+	if (kexec_flags & KEXEC_FLAGS_IS_KEXECED_KERNEL)
+		kexec_restore_backup();
+	save_processor_state();
+	error = machine_kexec_jump();
+	restore_processor_state();
+
+	/* NOTE:  device_power_up() is just a resume() for devices
+	 * that suspended with irqs off ... no overall powerup.
+	 */
+	device_power_up();
+ Enable_irqs:
+	local_irq_enable();
+ Enable_cpus:
+	enable_nonboot_cpus();
+ Resume_devices:
+	device_resume();
+	if (!error) {
+		kimage_free(kexec_crash_image);
+		kexec_crash_image = NULL;
+	}
+	return error;
+}
+#endif /* CONFIG_KEXEC_JUMP */
Index: linux-2.6/kernel/ksysfs.c
===================================================================
--- linux-2.6.orig/kernel/ksysfs.c	2007-07-14 14:52:45.000000000 +0800
+++ linux-2.6/kernel/ksysfs.c	2007-07-14 17:55:46.000000000 +0800
@@ -60,6 +60,15 @@
 	return sprintf(page, "%d\n", !!kexec_crash_image);
 }
 KERNEL_ATTR_RO(kexec_crash_loaded);
+
+#ifdef CONFIG_KEXEC_JUMP
+static ssize_t kexec_jump_buf_pfn_show(struct kset *kset, char *page)
+{
+	return sprintf(page, "0x%lx\n", kexec_get_jump_buf_pfn(1));
+}
+
+KERNEL_ATTR_RO(kexec_jump_buf_pfn);
+#endif
 #endif /* CONFIG_KEXEC */
 
 decl_subsys(kernel, NULL, NULL);
@@ -73,6 +82,9 @@
 #ifdef CONFIG_KEXEC
 	&kexec_loaded_attr.attr,
 	&kexec_crash_loaded_attr.attr,
+#ifdef CONFIG_KEXEC_JUMP
+	&kexec_jump_buf_pfn_attr.attr,
+#endif
 #endif
 	NULL
 };
Index: linux-2.6/arch/i386/kernel/kexec_jump.S
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/arch/i386/kernel/kexec_jump.S	2007-07-15 11:26:51.000000000 +0800
@@ -0,0 +1,74 @@
+/*
+ * kexec_jump.S - Jump between normal kernel and kexeced kernel
+ * Copyright (C) 2007 Huang Ying <ying.huang at intel.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include <linux/linkage.h>
+#include <linux/kexec.h>
+#include <asm/page.h>
+#include <asm/kexec.h>
+
+/*
+ * Must be relocatable PIC code callable as a C function
+ */
+#define HALF_PAGE_ALIGNED (1 << (PAGE_SHIFT-1))
+
+#define EBX	0x0
+#define ESI	0x4
+#define EDI	0x8
+#define EBP	0xc
+#define ESP	0x10
+#define CR0	0x14
+#define CR3	0x18
+#define CR4	0x1c
+#define FLAG	0x20
+#define RET	0x24
+
+	.text
+	.align HALF_PAGE_ALIGNED
+	.globl machine_kexec_real_jump
+machine_kexec_real_jump:
+	movl	4(%esp), %edx
+	movl	kexec_flags, %ecx
+	andl	$KEXEC_FLAGS_IS_KEXECED_KERNEL, %ecx
+	jnz	1f
+	movl	%ebx, EBX(%edx)
+	movl	%esi, ESI(%edx)
+	movl	%edi, EDI(%edx)
+	movl	%ebp, EBP(%edx)
+	movl	%esp, ESP(%edx)
+	movl	%cr0, %eax
+	movl	%eax, CR0(%edx)
+	movl	%cr3, %eax
+	movl	%eax, CR3(%edx)
+	movl	%cr4, %eax
+	movl	%eax, CR4(%edx)
+	pushf
+	popl	%eax
+	movl	%eax, FLAG(%edx)
+	movl	(%esp), %eax
+	movl	%eax, RET(%edx)
+	mov	$0, %eax
+	ret
+1:
+	movl	EBX(%edx), %ebx
+	movl	ESI(%edx), %esi
+	movl	EDI(%edx), %edi
+	movl	EBP(%edx), %ebp
+	movl	FLAG(%edx), %eax
+	pushl	%eax
+	popf
+	movl	ESP(%edx), %esp
+	movl	CR4(%edx), %eax
+	movl	%eax, %cr4
+	movl	CR3(%edx), %eax
+	movl	%eax, %cr3
+	movl	CR0(%edx), %eax
+	movl	%eax, %cr0
+	movl	RET(%edx), %eax
+	movl	%eax, (%esp)
+	mov	$1, %eax
+	ret
Index: linux-2.6/kernel/sys.c
===================================================================
--- linux-2.6.orig/kernel/sys.c	2007-07-14 16:45:21.000000000 +0800
+++ linux-2.6/kernel/sys.c	2007-07-14 17:39:47.000000000 +0800
@@ -940,6 +940,14 @@
 		unlock_kernel();
 		return -EINVAL;
 
+	case LINUX_REBOOT_CMD_KJUMP:
+		{
+			int ret;
+			ret = kexec_jump();
+			unlock_kernel();
+			return ret;
+		}
+
 #ifdef CONFIG_SOFTWARE_SUSPEND
 	case LINUX_REBOOT_CMD_SW_SUSPEND:
 		{
Index: linux-2.6/include/linux/reboot.h
===================================================================
--- linux-2.6.orig/include/linux/reboot.h	2007-07-14 17:29:58.000000000 +0800
+++ linux-2.6/include/linux/reboot.h	2007-07-14 20:43:04.000000000 +0800
@@ -33,6 +33,7 @@
 #define	LINUX_REBOOT_CMD_RESTART2	0xA1B2C3D4
 #define	LINUX_REBOOT_CMD_SW_SUSPEND	0xD000FCE2
 #define	LINUX_REBOOT_CMD_KEXEC		0x45584543
+#define	LINUX_REBOOT_CMD_KJUMP		0x3928A5FD
 
 
 #ifdef __KERNEL__
Index: linux-2.6/arch/i386/Kconfig
===================================================================
--- linux-2.6.orig/arch/i386/Kconfig	2007-07-14 17:52:02.000000000 +0800
+++ linux-2.6/arch/i386/Kconfig	2007-07-14 19:08:37.000000000 +0800
@@ -813,6 +813,13 @@
           PHYSICAL_START.
 	  For more details see Documentation/kdump/kdump.txt
 
+config KEXEC_JUMP
+	bool "kexec jump (EXPERIMENTAL)"
+	depends on EXPERIMENTAL
+	depends on PM && X86_32 && KEXEC
+	---help---
+	  Jump back from kexeced kernel to orignal kernel.
+
 config PHYSICAL_START
 	hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
 	default "0x100000"


From rjw at sisk.pl  Sun Jul 15 06:09:05 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Sun, 15 Jul 2007 12:09:05 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184483593.1898.98.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
Message-ID: <200707151209.06529.rjw@sisk.pl>

On Sunday, 15 July 2007 09:13, Huang, Ying wrote:
> The changelog between v1 and v2
> 
> 1. The kexec jump implementation is put into the kexec/kdump
>    framework instead of software suspend framework. The device
>    and CPU state save/restore code of software suspend is called
>    when needed.
> 
> 2. The same code path is used for both kexec a new kernel and jump
>    back to original kernel.
> 
> The complete changelog of the patch is as follow:
> 
> ---
> 
> Kexec base hibernation has some potential advantages over uswsusp and
> TuxOnIce (suspend2). Some most obvious advantages are:
> 
> 1. The hibernation image size can exceed half of memory size easily.

In TuxOnIce (suspend2) there's no such limitation.

> 2. The hibernation image can be written to and read from almost
>    anywhere, such as USB disk, NFS.

You can do this, too, with uswsusp.

> This patch implements the functionality of "jumping from kexeced
> kernel to original kernel". That is, the following sequence is
> possible:
> 
> 1. Boot a kernel A
> 2. Work under kernel A
> 3. Kexec another kernel B in kernel A
> 4. Work under kernel B
> 5. Jump from kernel B to kernel A
> 6. Continue work under kernel A
> 
> This is the first step to implement kexec based hibernation. If the
> memory image of kernel A is written to or read from a permanent media
> in step 4, a preliminary version of kexec based hibernation can be
> implemented.
> 
> The kernel B run as a crashdump kernel in reserved memory region. This
> is the biggest constrains of the patch. It is planed to be eliminated
> in the future version. That is, instead of reserving memory region
> previously, the needed memory region is backupped before kexec and
> restored after jumping back.
> 
> Another constrains of the patch is that the CONFIG_ACPI must be turned
> off to make kexec jump work. Because ACPI will put devices into low
> power state, the kexeced kernel can not be booted properly under
> it. This constrains can be eliminated by separating the suspend method
> and hibernate method of the devices as proposed earlier in the LKML.
> 
> The kexec jump is implemented in the framework of kexec/kdump. In
> sys_reboot, a new command named LINUX_REBOOT_CMD_KJUMP is defined to
> trigger the jumping to (executing) the new kernel or jump back to the
> original kernel.
> 
> Now, only the i386 architecture is supported. The patch is based on
> Linux kernel 2.6.22, and has been tested on my IBM T42.
> 
> Usage:
> 
> 1. Compile kernel with following options selected:
> 
> CONFIG_X86_32=y
> CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
> CONFIG_KEXEC=y
> CONFIG_PM=y
> CONFIG_KEXEC_JUMP=y
> 
> 2. Compile the kexec-tools with kdump and kjump patches, the
>    kdump patch can be found at:
> 
> http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump10.patch
> 
>    While, the kexec-tools kjump patch is appended with the mail.
> 
> 3. Boot kernel compiled for normal usage, the reserved crash kernel
>    memory region must be added to kernel command line as following:
> 
>    crashkernel=<XX>M@<XX>M
> 
>    Where, <XX> should be replaced by the real memory size and position.
> 
> 4. Load kernel compiled for hibernating usage as a crashdump kernel
>    with kexec, the same kernel as that of 3 can be used if
>    CONFIG_RELOCATABLE=y is selected. The kernel command line option as
>    following must be appended to kernel command line.
> 
>    kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`
> 
>    For example, the shell command line can be as follow:
> 
>    kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal
>        kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"
> 
> 5. Boot the hibernating kernel with following shell command line:
> 
>    kexec -j
> 
> 6. In the kexec booted kernel, trigger the jumping back with following
>    shell command.
> 
>    kexec -j

Well, I think that's _way_ too much complicated to be useful for hibernation
on systems that are set up and administered by average users.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From nigel at nigel.suspend2.net  Sun Jul 15 05:08:04 2007
From: nigel at nigel.suspend2.net (Nigel Cunningham)
Date: Sun, 15 Jul 2007 19:08:04 +1000
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184483593.1898.98.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
Message-ID: <200707151908.05388.nigel@nigel.suspend2.net>

Hi.

On Sunday 15 July 2007 17:13:13 Huang, Ying wrote:
> The complete changelog of the patch is as follow:
> 
> ---
> 
> Kexec base hibernation has some potential advantages over uswsusp and
> TuxOnIce (suspend2). Some most obvious advantages are:
> 
> 1. The hibernation image size can exceed half of memory size easily.
> 2. The hibernation image can be written to and read from almost
>    anywhere, such as USB disk, NFS.

This isn't right. TuxOnIce has no problem with image sizes exceeding half the 
amount of memory, and both uswsusp and TuxOnIce could write to a USB disk/key 
or NFS as well. Historically, the issue with writing to USB devices has been 
an issue with USB device drivers, not hibernation implementations. I haven't 
tried writing an image to USB, but with the work on the drivers, I wouldn't 
be surprised if it was usable now. NFS? Again, I haven't tried, but wouldn't 
expect it to be impossible. I did try writing an image to an NBD device a 
couple of years ago. It didn't quite work, but wasn't far away.
 
Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/kexec/attachments/20070715/2c52b7ce/attachment.bin 

From vgoyal at in.ibm.com  Mon Jul 16 00:19:19 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 16 Jul 2007 09:49:19 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070713131550.GB10985@suse.de>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
Message-ID: <20070716041918.GA11390@in.ibm.com>

On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> * Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-13 13:05]:
> > 
> > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > While 2nd-kernel is running, new makedumpfile comes to consider
> > 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> > from a mkdfinfo file.
> 
> I don't think that's a good idea. IMO the kernel should be modified to
> export the page size in a variable for that purpose. That would solve
> all problems and dependencies, doesn't it?
> 

Agreed. We need to export PAGESIZE from kernel instead of assuming that
second kernel as got same page size as first kernel.

Thanks
Vivek


From bwalle at suse.de  Mon Jul 16 07:57:07 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Mon, 16 Jul 2007 13:57:07 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716041918.GA11390@in.ibm.com>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
Message-ID: <20070716115707.GA29923@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 06:19]:
> On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > * Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-13 13:05]:
> > > 
> > > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > > While 2nd-kernel is running, new makedumpfile comes to consider
> > > 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> > > from a mkdfinfo file.
> > 
> > I don't think that's a good idea. IMO the kernel should be modified to
> > export the page size in a variable for that purpose. That would solve
> > all problems and dependencies, doesn't it?
> > 
> 
> Agreed. We need to export PAGESIZE from kernel instead of assuming that
> second kernel as got same page size as first kernel.

So what about this? Do you think it has a chance to get included?
Should the variable not be inside mm/ but otherwhere?


Signed-off-by: Bernhard Walle <bwalle at suse.de>

---
 mm/mmap.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -35,6 +35,16 @@
 #define arch_mmap_check(addr, len, flags)	(0)
 #endif
 
+#ifdef CONFIG_KEXEC
+
+/*
+ * Although that variable is not needed for the kernel, initialise it here
+ * to have the page size available in the vmlinux binary.
+ */
+int page_size = PAGE_SIZE;
+
+#endif
+
 static void unmap_region(struct mm_struct *mm,
 		struct vm_area_struct *vma, struct vm_area_struct *prev,
 		unsigned long start, unsigned long end);


From vgoyal at in.ibm.com  Mon Jul 16 08:25:18 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 16 Jul 2007 17:55:18 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716115707.GA29923@suse.de>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
	<20070716115707.GA29923@suse.de>
Message-ID: <20070716122518.GA10506@in.ibm.com>

On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 06:19]:
> > On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > > * Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-13 13:05]:
> > > > 
> > > > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > > > While 2nd-kernel is running, new makedumpfile comes to consider
> > > > 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> > > > from a mkdfinfo file.
> > > 
> > > I don't think that's a good idea. IMO the kernel should be modified to
> > > export the page size in a variable for that purpose. That would solve
> > > all problems and dependencies, doesn't it?
> > > 
> > 
> > Agreed. We need to export PAGESIZE from kernel instead of assuming that
> > second kernel as got same page size as first kernel.
> 
> So what about this? Do you think it has a chance to get included?
> Should the variable not be inside mm/ but otherwhere?
> 
> 
> Signed-off-by: Bernhard Walle <bwalle at suse.de>
> 
> ---
>  mm/mmap.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -35,6 +35,16 @@
>  #define arch_mmap_check(addr, len, flags)	(0)
>  #endif
> 
> +#ifdef CONFIG_KEXEC
> +
> +/*
> + * Although that variable is not needed for the kernel, initialise it here
> + * to have the page size available in the vmlinux binary.
> + */
> +int page_size = PAGE_SIZE;
> +

Ok. Now there seems to be two ways for accessing such info.
- Through global variables
- Export through ELF notes.

Personally, I like the approach taken by Dan Aloni of exporting required
info through ELF notes. That seems to be more standard in the sense we 
are not dependent on somebody removing above variable tomorrow.

Dan, are you planning to put the modified patch for discussions on LKML?

Thanks
Vivek


From bwalle at suse.de  Mon Jul 16 08:28:54 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Mon, 16 Jul 2007 14:28:54 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716122518.GA10506@in.ibm.com>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
	<20070716115707.GA29923@suse.de>
	<20070716122518.GA10506@in.ibm.com>
Message-ID: <20070716122854.GC32519@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 14:25]:
> 
> Ok. Now there seems to be two ways for accessing such info.
> - Through global variables
> - Export through ELF notes.
> 
> Personally, I like the approach taken by Dan Aloni of exporting required
> info through ELF notes. That seems to be more standard in the sense we 
> are not dependent on somebody removing above variable tomorrow.
> 
> Dan, are you planning to put the modified patch for discussions on LKML?

You mean the proposal with the makedumpfile-compatible ELF note?
Although I like that idea, I think Ken'ichi Ohmichi was against it.


Thanks,
   Bernhard


From vgoyal at in.ibm.com  Mon Jul 16 08:36:33 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 16 Jul 2007 18:06:33 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716122854.GC32519@suse.de>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
	<20070716115707.GA29923@suse.de>
	<20070716122518.GA10506@in.ibm.com>
	<20070716122854.GC32519@suse.de>
Message-ID: <20070716123633.GA10920@in.ibm.com>

On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 14:25]:
> > 
> > Ok. Now there seems to be two ways for accessing such info.
> > - Through global variables
> > - Export through ELF notes.
> > 
> > Personally, I like the approach taken by Dan Aloni of exporting required
> > info through ELF notes. That seems to be more standard in the sense we 
> > are not dependent on somebody removing above variable tomorrow.
> > 
> > Dan, are you planning to put the modified patch for discussions on LKML?
> 
> You mean the proposal with the makedumpfile-compatible ELF note?
> Although I like that idea, I think Ken'ichi Ohmichi was against it.
> 

Yes, makedumpfile compatible ELF note one. Ken'ichi did not like the idea
too much, but I am not sure we discussed his objections in detail. I had
also responded with a mail with some of the advantages of ELF note based
approach. No response on that.

Thanks
Vivek


From vgoyal at in.ibm.com  Mon Jul 16 23:50:55 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 17 Jul 2007 09:20:55 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716115707.GA29923@suse.de>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
	<20070716115707.GA29923@suse.de>
Message-ID: <20070717035055.GA4869@in.ibm.com>

On Mon, Jul 16, 2007 at 01:57:07PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 06:19]:
> > On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote:
> > > * Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-13 13:05]:
> > > > 
> > > > BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
> > > > While 2nd-kernel is running, new makedumpfile comes to consider
> > > > 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
> > > > from a mkdfinfo file.
> > > 
> > > I don't think that's a good idea. IMO the kernel should be modified to
> > > export the page size in a variable for that purpose. That would solve
> > > all problems and dependencies, doesn't it?
> > > 
> > 
> > Agreed. We need to export PAGESIZE from kernel instead of assuming that
> > second kernel as got same page size as first kernel.
> 
> So what about this? Do you think it has a chance to get included?
> Should the variable not be inside mm/ but otherwhere?
> 
> 
> Signed-off-by: Bernhard Walle <bwalle at suse.de>
> 
> ---
>  mm/mmap.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -35,6 +35,16 @@
>  #define arch_mmap_check(addr, len, flags)	(0)
>  #endif
> 
> +#ifdef CONFIG_KEXEC
> +
> +/*
> + * Although that variable is not needed for the kernel, initialise it here
> + * to have the page size available in the vmlinux binary.
> + */
> +int page_size = PAGE_SIZE;
> +

Thinking more about it. These config variables are accessible in user
space in first kernel through sysconf() interface. In that case kexec
can pack required config variables into an ELF note and kernel does not
have to intervene.

Thanks
Vivek


From bwalle at suse.de  Tue Jul 17 04:17:24 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 17 Jul 2007 10:17:24 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070717035055.GA4869@in.ibm.com>
References: <20070710120243.GA10121@hmsendeavour.rdu.redhat.com>
	<20070713200533oomichi@mail.jp.nec.com>
	<20070713131550.GB10985@suse.de>
	<20070716041918.GA11390@in.ibm.com>
	<20070716115707.GA29923@suse.de> <20070717035055.GA4869@in.ibm.com>
Message-ID: <20070717081724.GA16853@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-17 05:50]:
> 
> Thinking more about it. These config variables are accessible in user
> space in first kernel through sysconf() interface. In that case kexec
> can pack required config variables into an ELF note and kernel does not
> have to intervene.

That's a good point. So we'd only need to aggree on a format for all
this information. I think the makedumpfile format is quite good --
instead of inventing another new format.


Thanks,
   Bernhard


From david at lang.hm  Tue Jul 17 04:13:49 2007
From: david at lang.hm (david at lang.hm)
Date: Tue, 17 Jul 2007 01:13:49 -0700 (PDT)
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base	hibernation
In-Reply-To: <1184491804.1898.121.camel@caritas-dev.intel.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com> 
	<200707141159.47289.rjw@sisk.pl>
	<1184410554.1898.84.camel@caritas-dev.intel.com>
	<200707142116.10237.rjw@sisk.pl>
	<1184491804.1898.121.camel@caritas-dev.intel.com>
Message-ID: <Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>

Ying, as the kexec guru in this thread I have a question for you about how 
kexec works (and possibly where you are going with this)

for the power-off hibernate with ACPI disabled the hibernation seems 
fairly straightforward (although there are still some missing pieces)

however, since the resume designed for ACPI won't work would the following 
approach work

1. boot one kernel
2. setup a kexec the same way you would for hibernate
3. kexec to the new kernel
4. overwrite the memory of the first kernel
5. kexec 'back' to the main kernel that has now been overwritten by what was saved?

as part of this question, when you do a kexec, how does the kernel that 
you are doing the kexec to know what to run next?

it needs to do some initialization first before it starts running normal 
things, and at that point it the move back doesn't look for init like a 
normal kernel boot (or the system would effectivly boot instead of picking 
up where it left off)

is this 'restart point' flexible enough that either the pre-hibernate 
kerenl or the small hibernate kernel could tell the pre-hibernate kernel 
to go into suspend-to-ram mode before doing anything else?

Rafael,
   if ACPI is disabled and not used, is there any memory in the origional 
kernel that _must not_ be saved in the hibernate image? I recognise that 
for efficancy it would save time to not save free memory, but if I'm 
willing to waste some resources would it hurt to save everything?

David Lang


From fernando at oss.ntt.co.jp  Tue Jul 17 06:09:57 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Tue, 17 Jul 2007 19:09:57 +0900
Subject: [PATCH RFC] Debug handling of early spurious interrupts
Message-ID: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>

With the advent of kdump it is possible that device drivers receive
interrupts generated in the context of a previous kernel. Ideally
quiescing the underlying devices should suffice but not all drivers
do this, either because it is not possible or because they did not
contemplate this case. Thus drivers ought to be able to handle
interrupts coming in as soon as the interrupt handler is registered.

Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
---

diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22/kernel/irq/manage.c
--- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/kernel/irq/manage.c	2007-07-17 18:37:24.000000000 +0900
@@ -537,6 +537,29 @@ int request_irq(unsigned int irq, irq_ha
 
 	select_smp_affinity(irq);
 
+#if defined(CONFIG_DEBUG_PENDING_IRQ) || defined(CONFIG_DEBUG_SHIRQ)
+#ifndef CONFIG_DEBUG_PENDING_IRQ
+	if (irqflags & IRQF_SHARED) {
+		/*
+		 * It's a shared IRQ -- the driver ought to be prepared for it
+		 * to happen immediately, so let's make sure....
+		 * We do this before actually registering it, to make sure that
+		 * a 'real' IRQ doesn't run in parallel with our fake.
+		 */
+#endif /* !CONFIG_DEBUG_PENDING_IRQ */
+		if (irqflags & IRQF_DISABLED) {
+			unsigned long flags;
+
+			local_irq_save(flags);
+			handler(irq, dev_id);
+			local_irq_restore(flags);
+		} else
+			handler(irq, dev_id);
+#ifndef CONFIG_DEBUG_PENDING_IRQ
+	}
+#endif /* !CONFIG_DEBUG_PENDING_IRQ */
+#endif /* CONFIG_DEBUG_PENDING_IRQ || CONFIG_DEBUG_SHIRQ */
+
 #ifdef CONFIG_DEBUG_SHIRQ
 	if (irqflags & IRQF_SHARED) {
 		/*
diff -urNp linux-2.6.22-orig/lib/Kconfig.debug linux-2.6.22/lib/Kconfig.debug
--- linux-2.6.22-orig/lib/Kconfig.debug	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/lib/Kconfig.debug	2007-07-17 18:52:00.000000000 +0900
@@ -77,6 +77,17 @@ config DEBUG_KERNEL
 	  Say Y here if you are developing drivers or trying to debug and
 	  identify kernel problems.
 
+config DEBUG_PENDING_IRQ
+	bool "Debug handling of early spurious interrupts"
+	depends on DEBUG_KERNEL && GENERIC_HARDIRQS
+	help
+	  With the advent of kdump it is possible that device drivers receive
+	  interrupts generated in the context of a previous kernel. Ideally
+	  quiescing the underlying devices should suffice but not all drivers
+	  do this, either because it is not possible or because they did not
+	  contemplate this case. Thus drivers ought to be able to handle
+	  interrupts coming in as soon as the interrupt handler is registered.
+
 config DEBUG_SHIRQ
 	bool "Debug shared IRQ handlers"
 	depends on DEBUG_KERNEL && GENERIC_HARDIRQS




From rjw at sisk.pl  Tue Jul 17 07:59:31 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Tue, 17 Jul 2007 13:59:31 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec
	=?iso-8859-1?q?base=09hibernation?=
In-Reply-To: <Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<1184491804.1898.121.camel@caritas-dev.intel.com>
	<Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
Message-ID: <200707171359.33317.rjw@sisk.pl>

On Tuesday, 17 July 2007 10:13, david at lang.hm wrote:
> Ying, as the kexec guru in this thread I have a question for you about how 
> kexec works (and possibly where you are going with this)
> 
> for the power-off hibernate with ACPI disabled the hibernation seems 
> fairly straightforward (although there are still some missing pieces)
> 
> however, since the resume designed for ACPI won't work would the following 
> approach work
> 
> 1. boot one kernel
> 2. setup a kexec the same way you would for hibernate
> 3. kexec to the new kernel
> 4. overwrite the memory of the first kernel
> 5. kexec 'back' to the main kernel that has now been overwritten by what was saved?
> 
> as part of this question, when you do a kexec, how does the kernel that 
> you are doing the kexec to know what to run next?
> 
> it needs to do some initialization first before it starts running normal 
> things, and at that point it the move back doesn't look for init like a 
> normal kernel boot (or the system would effectivly boot instead of picking 
> up where it left off)
> 
> is this 'restart point' flexible enough that either the pre-hibernate 
> kerenl or the small hibernate kernel could tell the pre-hibernate kernel 
> to go into suspend-to-ram mode before doing anything else?
> 
> Rafael,
>    if ACPI is disabled and not used, is there any memory in the origional 
> kernel that _must not_ be saved in the hibernate image? I recognise that 
> for efficancy it would save time to not save free memory, but if I'm 
> willing to waste some resources would it hurt to save everything?

On some systems there are valid 'struct page' structures that correspond to
memory holes and the kernel will oops if you try to save the contents of
these pages.  Unfortunately, only the early initialization platform code can
tell you which they are.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From ying.huang at intel.com  Tue Jul 17 08:48:38 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Tue, 17 Jul 2007 20:48:38 +0800
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base	hibernation
In-Reply-To: <Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<200707141159.47289.rjw@sisk.pl>
	<1184410554.1898.84.camel@caritas-dev.intel.com>
	<200707142116.10237.rjw@sisk.pl>
	<1184491804.1898.121.camel@caritas-dev.intel.com>
	<Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
Message-ID: <1184676518.10998.34.camel@caritas-dev.intel.com>

On Tue, 2007-07-17 at 01:13 -0700, david at lang.hm wrote:
> however, since the resume designed for ACPI won't work would the following 
> approach work
> 
> 1. boot one kernel
> 2. setup a kexec the same way you would for hibernate
> 3. kexec to the new kernel
> 4. overwrite the memory of the first kernel
> 5. kexec 'back' to the main kernel that has now been overwritten by what was saved?
> 
> as part of this question, when you do a kexec, how does the kernel that 
> you are doing the kexec to know what to run next?

For kernel in 3 that do kexec, the devices and CPU state are saved into
memory before executing the new kernel. So when jumping back, the
control will continue from kexec point. If the memory image of main
kernel is restored from disk, the devices and CPU state in memory is
restored too. Before jumping back in 5, the devices are put in the known
state, after jumping back, the devices and CPU state is restored. If the
"kexec -j" is used to trigger the kexec in 3, the system will continue
with "kexec -j" exiting with exit code 0.

> it needs to do some initialization first before it starts running normal 
> things, and at that point it the move back doesn't look for init like a 
> normal kernel boot (or the system would effectivly boot instead of picking 
> up where it left off)

I think the early initialization can be done in a initramfs. At that
point, the resume image can be checked, the next step depends on the
result of checking.

> is this 'restart point' flexible enough that either the pre-hibernate 
> kerenl or the small hibernate kernel could tell the pre-hibernate kernel 
> to go into suspend-to-ram mode before doing anything else?

It is possible for hibernate kernel to pass information back to
pre-hibernate kernel. For example, the information can be passed in jump
buffer page. 

Best Regards,
Huang Ying


From bwalle at suse.de  Tue Jul 17 09:56:16 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 17 Jul 2007 15:56:16 +0200
Subject: [PATCH] [makedumpfile] Introduce -f (force) option
Message-ID: <20070717135615.GA19864@suse.de>

As I always forget to delete the produced dump file when testing
something, I'd like to see a `-f' option that forces makedumpfile to
overwrite existing files.


Signed-off-by: Bernhard Walle <bwalle at suse.de>

---
 makedumpfile.8 |   10 ++++++++++
 makedumpfile.c |   11 +++++++++--
 makedumpfile.h |    1 +
 3 files changed, 20 insertions(+), 2 deletions(-)

--- a/makedumpfile.8
+++ b/makedumpfile.8
@@ -144,6 +144,16 @@ support compressed data.
 # makedumpfile \-E \-d 31 \-x vmlinux /proc/vmcore dumpfile
 
 .TP
+\fB\-f\fR
+Force existing files to be overwritten.
+.br
+.B Example:
+.br
+# makedumpfile \-f \-x vmlinux /proc/vmcore dumpfile
+.br
+This command overwrites \fIdumpfile\fR if it already exists.
+
+.TP
 \fB\-x\fR \fIVMLINUX\fR
 Specify the first kernel's \fIVMLINUX\fR with debug information to analyze the
 first kernel's memory usage.
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -409,6 +409,10 @@ int
 open_dump_file(struct DumpInfo *info)
 {
 	int fd;
+	int open_flags = O_RDWR|O_CREAT;
+
+	if (!info->flag_force)
+		open_flags |= O_EXCL;
 
 	if (info->flag_flatten) {
 		if ((info->name_dumpfile
@@ -420,7 +424,7 @@ open_dump_file(struct DumpInfo *info)
 		fd = STDOUT_FILENO;
 		strcpy(info->name_dumpfile, FILENAME_STDOUT);
 
-	} else if ((fd = open(info->name_dumpfile, O_RDWR|O_CREAT|O_EXCL,
+	} else if ((fd = open(info->name_dumpfile, open_flags,
 	    S_IRUSR|S_IWUSR)) < 0) {
 		ERRMSG("Can't open the dump file(%s). %s\n",
 		    info->name_dumpfile, strerror(errno));
@@ -4624,7 +4628,7 @@ main(int argc, char *argv[])
 	vt = &info->vm_table;
 
 	info->block_order = DEFAULT_ORDER;
-	while ((opt = getopt(argc, argv, "b:cDd:EFg:hi:Rvx:")) != -1) {
+	while ((opt = getopt(argc, argv, "b:cDd:EFg:hi:Rvx:f")) != -1) {
 		switch (opt) {
 		case 'b':
 			info->block_order = atoi(optarg);
@@ -4646,6 +4650,9 @@ main(int argc, char *argv[])
 		case 'F':
 			info->flag_flatten = 1;
 			break;
+		case 'f':
+			info->flag_force = 1;
+			break;
 		case 'g':
 			info->flag_generate_config = 1;
 			info->name_configfile = optarg;
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -552,6 +552,7 @@ struct DumpInfo {
 						format to a standard out */
 	int		flag_rearrange;      /* flag of creating dumpfile from
 						flattened format */
+	int		flag_force;	     /* overwrite existing stuff */
 	long		page_size;           /* size of page */
 	long		page_shift;
 	unsigned long long	max_mapnr;   /* number of page descriptor */


From rjw at sisk.pl  Tue Jul 17 10:22:52 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Tue, 17 Jul 2007 16:22:52 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec
	=?iso-8859-15?q?base=09hibernation?=
In-Reply-To: <1184676518.10998.34.camel@caritas-dev.intel.com>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
	<1184676518.10998.34.camel@caritas-dev.intel.com>
Message-ID: <200707171622.53657.rjw@sisk.pl>

On Tuesday, 17 July 2007 14:48, Huang, Ying wrote:
> On Tue, 2007-07-17 at 01:13 -0700, david at lang.hm wrote:
> > however, since the resume designed for ACPI won't work would the following 
> > approach work
> > 
> > 1. boot one kernel
> > 2. setup a kexec the same way you would for hibernate
> > 3. kexec to the new kernel
> > 4. overwrite the memory of the first kernel
> > 5. kexec 'back' to the main kernel that has now been overwritten by what was saved?
> > 
> > as part of this question, when you do a kexec, how does the kernel that 
> > you are doing the kexec to know what to run next?
> 
> For kernel in 3 that do kexec, the devices and CPU state are saved into
> memory before executing the new kernel. So when jumping back, the
> control will continue from kexec point. If the memory image of main
> kernel is restored from disk, the devices and CPU state in memory is
> restored too. Before jumping back in 5, the devices are put in the known
> state, after jumping back, the devices and CPU state is restored. If the
> "kexec -j" is used to trigger the kexec in 3, the system will continue
> with "kexec -j" exiting with exit code 0.
> 
> > it needs to do some initialization first before it starts running normal 
> > things, and at that point it the move back doesn't look for init like a 
> > normal kernel boot (or the system would effectivly boot instead of picking 
> > up where it left off)
> 
> I think the early initialization can be done in a initramfs. At that
> point, the resume image can be checked, the next step depends on the
> result of checking.
> 
> > is this 'restart point' flexible enough that either the pre-hibernate 
> > kerenl or the small hibernate kernel could tell the pre-hibernate kernel 
> > to go into suspend-to-ram mode before doing anything else?
> 
> It is possible for hibernate kernel to pass information back to
> pre-hibernate kernel. For example, the information can be passed in jump
> buffer page. 

I think it would be reasonable to have a protocol defined for passing this
information, so that it's independent of the kernel version etc.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From david at lang.hm  Tue Jul 17 20:25:29 2007
From: david at lang.hm (david at lang.hm)
Date: Tue, 17 Jul 2007 17:25:29 -0700 (PDT)
Subject: [PATCH 0/2] Kexec jump: The first step to kexec
	=?iso-8859-15?q?base=09hibernation?=
In-Reply-To: <200707171622.53657.rjw@sisk.pl>
References: <1184167831.12556.13.camel@caritas-dev.intel.com>
	<Pine.LNX.4.64.0707170101010.19248@asgard.lang.hm>
	<1184676518.10998.34.camel@caritas-dev.intel.com>
	<200707171622.53657.rjw@sisk.pl>
Message-ID: <Pine.LNX.4.64.0707171707380.2467@asgard.lang.hm>

On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

> On Tuesday, 17 July 2007 14:48, Huang, Ying wrote:
>> On Tue, 2007-07-17 at 01:13 -0700, david at lang.hm wrote:
>>> however, since the resume designed for ACPI won't work would the following
>>> approach work
>>>
>>> 1. boot one kernel
>>> 2. setup a kexec the same way you would for hibernate
>>> 3. kexec to the new kernel
>>> 4. overwrite the memory of the first kernel
>>> 5. kexec 'back' to the main kernel that has now been overwritten by what was saved?
>>>
>>> as part of this question, when you do a kexec, how does the kernel that
>>> you are doing the kexec to know what to run next?
>>
>> For kernel in 3 that do kexec, the devices and CPU state are saved into
>> memory before executing the new kernel. So when jumping back, the
>> control will continue from kexec point. If the memory image of main
>> kernel is restored from disk, the devices and CPU state in memory is
>> restored too. Before jumping back in 5, the devices are put in the known
>> state, after jumping back, the devices and CPU state is restored. If the
>> "kexec -j" is used to trigger the kexec in 3, the system will continue
>> with "kexec -j" exiting with exit code 0.
>>
>>> it needs to do some initialization first before it starts running normal
>>> things, and at that point it the move back doesn't look for init like a
>>> normal kernel boot (or the system would effectivly boot instead of picking
>>> up where it left off)
>>
>> I think the early initialization can be done in a initramfs. At that
>> point, the resume image can be checked, the next step depends on the
>> result of checking.
>>
>>> is this 'restart point' flexible enough that either the pre-hibernate
>>> kerenl or the small hibernate kernel could tell the pre-hibernate kernel
>>> to go into suspend-to-ram mode before doing anything else?
>>
>> It is possible for hibernate kernel to pass information back to
>> pre-hibernate kernel. For example, the information can be passed in jump
>> buffer page.
>
> I think it would be reasonable to have a protocol defined for passing this
> information, so that it's independent of the kernel version etc.

At this point it looks like we have the following communication nessasary 
between the two kernels

1. the original kernel needs to create a map of what memory to backup

   this could be either a bitmap, or a series of address:blockcount pairs.
   in either case the result could be sizeable, so it's probably best to 
define a standard location to find the type and address of the data.

2. the new kernel needs to tell the old kernel which 'restart point' to 
use.

   this could be a simple jump table.

   the list that has been suggested so far is
     A. restore (the default)
     B. suspend-to-ram
     C. ACPI suspend-to-disk (S4 mode)

since both kernels have access to the other kernel's memory the data could 
be stored in either kernel's address space, but my initial thought is that 
it's cleaner to store this in the original kernel's space and have the 
second kernel find it there.

I don't have the knowledge to create either of these interfaces, let alone 
the pull to get them implmented in the kernel.

could I ask that one of you consider makeing a patch that implements at 
least #1 (the memory map)

it sounds as if these kexec-back patches plus makeing the memory map 
available would allow for a ACPI-free hibernate mode with no other 
modifications. I'd like to try experimenting with this, but without the 
memory map it sounds as if things will croak when I try to do this.

David Lang


From oomichi at mxs.nes.nec.co.jp  Wed Jul 18 10:07:40 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Wed, 18 Jul 2007 23:07:40 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070716123633.GA10920@in.ibm.com>
References: <20070716123633.GA10920@in.ibm.com>
Message-ID: <20070718230740oomichi@mail.jp.nec.com>


Hi,

2007/07/16 18:06:33 +0530, Vivek Goyal <vgoyal at in.ibm.com> wrote:
>On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
>> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 14:25]:
>> > 
>> > Ok. Now there seems to be two ways for accessing such info.
>> > - Through global variables
>> > - Export through ELF notes.
>> > 
>> > Personally, I like the approach taken by Dan Aloni of exporting required
>> > info through ELF notes. That seems to be more standard in the sense we 
>> > are not dependent on somebody removing above variable tomorrow.
>> > 
>> > Dan, are you planning to put the modified patch for discussions on LKML?
>> 
>> You mean the proposal with the makedumpfile-compatible ELF note?
>> Although I like that idea, I think Ken'ichi Ohmichi was against it.
>> 
>
>Yes, makedumpfile compatible ELF note one. Ken'ichi did not like the idea
>too much, but I am not sure we discussed his objections in detail. I had
>also responded with a mail with some of the advantages of ELF note based
>approach. No response on that.

Sorry for my delayed response, I took a short vacation.

I'm not against with the proposal adding PT_NOTE segment to /proc/vmcore.
I don't like only point that adds the necessary information list
(some symbols, structures, etc.) for makedumpfile to kernel code.

The content of mkdfinfo file has been increasing whenever adding
features and correcting bugs. The content is increasing even now.
And, the feature addition is done not only for new kernels but also
for old upstream kernels. When the content of mkdfinfo file is taken 
into the kernel and fixed, the feature addition in the future is
remarkably limited. So makedumpfile needs mkdfinfo file outside of
the kernel.

I propose the solution including Dan's, Vivek's and Bernhard's opinions.
How about the following sequence for distributors ?
(It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
 A new option "--mkdfinfo" is added to kexec command.)

* On the kernel building system
  1. Create the kernel files.
     # cd linux-2.6.xx
     # make
  2. Create the mkdfinfo file from the vmlinux.
     # makedumpfile -g mkdfinfo-2.6.xx -x vmlinux
     (OSRELEASE is taken from the vmlinux.)
  3. Pack the kernel package with the kernel files and the mkdfinfo file.

* On each system
  4. Preload 2nd-kernel and the mkdfinfo file.
     # kexec -p vmlinux-kdump --mkdfinfo=mkdfinfo-2.6.xx ...
     - 2nd-kernel is preloaded.
     - 1st-kernel's PAGESIZE is taken by sysconf().
     - The mkdfinfo file and the above PAGESIZE is preloaded
       into /proc/vmcore's PT_NOTE segment.
  5. Panic happens, and the system switchs to 2nd-kernel.
  6. Create a filtered dump file.
     # makedumpfile -cd31 /proc/vmcore dumpfile
     (User doesn't need to specify the mkdfinfo file, because the
      contents of the mkdfinfo file is included into /proc/vmcore.)


Thanks
Ken'ichi Ohmichi


From akpm at linux-foundation.org  Wed Jul 18 18:46:59 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 18 Jul 2007 15:46:59 -0700
Subject: [PATCH RFC] Debug handling of early spurious interrupts
In-Reply-To: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <20070718154659.c8b5ffea.akpm@linux-foundation.org>

On Tue, 17 Jul 2007 19:09:57 +0900
Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:

> With the advent of kdump it is possible that device drivers receive
> interrupts generated in the context of a previous kernel. Ideally
> quiescing the underlying devices should suffice but not all drivers
> do this, either because it is not possible or because they did not
> contemplate this case. Thus drivers ought to be able to handle
> interrupts coming in as soon as the interrupt handler is registered.
> 
> Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
> ---
> 
> diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22/kernel/irq/manage.c
> --- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-09 08:32:17.000000000 +0900
> +++ linux-2.6.22/kernel/irq/manage.c	2007-07-17 18:37:24.000000000 +0900
> @@ -537,6 +537,29 @@ int request_irq(unsigned int irq, irq_ha
>  
>  	select_smp_affinity(irq);
>  
> +#if defined(CONFIG_DEBUG_PENDING_IRQ) || defined(CONFIG_DEBUG_SHIRQ)
> +#ifndef CONFIG_DEBUG_PENDING_IRQ
> +	if (irqflags & IRQF_SHARED) {
> +		/*
> +		 * It's a shared IRQ -- the driver ought to be prepared for it
> +		 * to happen immediately, so let's make sure....
> +		 * We do this before actually registering it, to make sure that
> +		 * a 'real' IRQ doesn't run in parallel with our fake.
> +		 */
> +#endif /* !CONFIG_DEBUG_PENDING_IRQ */
> +		if (irqflags & IRQF_DISABLED) {
> +			unsigned long flags;
> +
> +			local_irq_save(flags);
> +			handler(irq, dev_id);
> +			local_irq_restore(flags);
> +		} else
> +			handler(irq, dev_id);
> +#ifndef CONFIG_DEBUG_PENDING_IRQ
> +	}
> +#endif /* !CONFIG_DEBUG_PENDING_IRQ */
> +#endif /* CONFIG_DEBUG_PENDING_IRQ || CONFIG_DEBUG_SHIRQ */

Even if we were going to merge this functionality as-is, I'd ask for some
sort of refactoring to fix up that ifdef maze.

But more substantial issues:

- This is presented as a "debug" feature, but it isn't a debug feature at
  all - it is new functionality which is unrelated to kernel development.

  Also, it is a "debug" feature which provides no debugging!  At the very
  least, one would expect to see it emit a printk to tell people that we
  have some driver which needs fixing.

  Also, this not-really-a-debug-feature is undesirably coupled with a
  real debugging feature: CONFIG_DEBUG_PENDING_IRQ.

- Does this new feature really need its own Kconfig setting?  Why not enable
  it unconditionally?  request_irq() isn't exactly performance-critical.

- If poss, we really do want to find some way of emitting a warning when
  we detect such a device driver.  Like, call the handler and if it
  returned IRQ_HANDLED, start shouting.




From bwalle at suse.de  Wed Jul 18 19:10:50 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 19 Jul 2007 01:10:50 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070718230740oomichi@mail.jp.nec.com>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
Message-ID: <20070718231050.GB25660@suse.de>

Hello,

* Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> [2007-07-18 16:07]:
> I propose the solution including Dan's, Vivek's and Bernhard's opinions.
> How about the following sequence for distributors ?
> (It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
>  A new option "--mkdfinfo" is added to kexec command.)
> 
> * On the kernel building system
>   1. Create the kernel files.
>      # cd linux-2.6.xx
>      # make
>   2. Create the mkdfinfo file from the vmlinux.
>      # makedumpfile -g mkdfinfo-2.6.xx -x vmlinux
>      (OSRELEASE is taken from the vmlinux.)
>   3. Pack the kernel package with the kernel files and the mkdfinfo file.
> 
> * On each system
>   4. Preload 2nd-kernel and the mkdfinfo file.
>      # kexec -p vmlinux-kdump --mkdfinfo=mkdfinfo-2.6.xx ...
>      - 2nd-kernel is preloaded.
>      - 1st-kernel's PAGESIZE is taken by sysconf().
>      - The mkdfinfo file and the above PAGESIZE is preloaded
>        into /proc/vmcore's PT_NOTE segment.
>   5. Panic happens, and the system switchs to 2nd-kernel.
>   6. Create a filtered dump file.
>      # makedumpfile -cd31 /proc/vmcore dumpfile
>      (User doesn't need to specify the mkdfinfo file, because the
>       contents of the mkdfinfo file is included into /proc/vmcore.)

I like the proposal. The advantage over exporting the needed
information from the kernel directly is that makedumpfile (and the
contents of the mkdfinfo file [1]) can be changed without changing the
kernel which simplifies maintenance.

If now everybody agrees that this is the way to go, I can also offer
to implement the kernel and kexec userspace utility part
implementation of that stuff.

Maybe we should wait until Simon Horman is back here as he's the
current maintainer of kexec-tools(-testing).


Thanks,
   Bernhard

[1] didn't we agree to vmcoreinfo?


From akpm at linux-foundation.org  Wed Jul 18 21:04:20 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 18 Jul 2007 18:04:20 -0700
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184483593.1898.98.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
Message-ID: <20070718180420.02352d4f.akpm@linux-foundation.org>

On Sun, 15 Jul 2007 15:13:13 +0800
"Huang, Ying" <ying.huang at intel.com> wrote:

> 
> The changelog between v1 and v2
> 
> 1. The kexec jump implementation is put into the kexec/kdump
>    framework instead of software suspend framework. The device
>    and CPU state save/restore code of software suspend is called
>    when needed.
> 
> 2. The same code path is used for both kexec a new kernel and jump
>    back to original kernel.

I like the idea but I think I'll let people chat about it a bit more
before looking at merging the patches, OK?


From nigel at nigel.suspend2.net  Wed Jul 18 22:15:04 2007
From: nigel at nigel.suspend2.net (Nigel Cunningham)
Date: Thu, 19 Jul 2007 12:15:04 +1000
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <20070718180420.02352d4f.akpm@linux-foundation.org>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070718180420.02352d4f.akpm@linux-foundation.org>
Message-ID: <200707191215.05245.nigel@nigel.suspend2.net>

Hi.

On Thursday 19 July 2007 11:04:20 Andrew Morton wrote:
> On Sun, 15 Jul 2007 15:13:13 +0800
> "Huang, Ying" <ying.huang at intel.com> wrote:
> 
> > 
> > The changelog between v1 and v2
> > 
> > 1. The kexec jump implementation is put into the kexec/kdump
> >    framework instead of software suspend framework. The device
> >    and CPU state save/restore code of software suspend is called
> >    when needed.
> > 
> > 2. The same code path is used for both kexec a new kernel and jump
> >    back to original kernel.
> 
> I like the idea but I think I'll let people chat about it a bit more
> before looking at merging the patches, OK?

Please wait until you see a complete implementation that actually works. I'm 
sitting here quietly, following (and now breaking) the "If you can't say 
anything positive, don't say anything at all" line because I think that the 
more into the implementation details people get, the uglier this is going to 
show itself to be. I'm perfectly willing to be proven wrong, but haven't seen 
anything so far that's even begun to convince me otherwise.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/kexec/attachments/20070719/da287a38/attachment.bin 

From david at lang.hm  Wed Jul 18 23:30:47 2007
From: david at lang.hm (david at lang.hm)
Date: Wed, 18 Jul 2007 20:30:47 -0700 (PDT)
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <200707191215.05245.nigel@nigel.suspend2.net>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070718180420.02352d4f.akpm@linux-foundation.org>
	<200707191215.05245.nigel@nigel.suspend2.net>
Message-ID: <Pine.LNX.4.64.0707182026130.19248@asgard.lang.hm>

On Thu, 19 Jul 2007, Nigel Cunningham wrote:

> Hi.
>
> On Thursday 19 July 2007 11:04:20 Andrew Morton wrote:
>> On Sun, 15 Jul 2007 15:13:13 +0800
>> "Huang, Ying" <ying.huang at intel.com> wrote:
>>
>>>
>>> The changelog between v1 and v2
>>>
>>> 1. The kexec jump implementation is put into the kexec/kdump
>>>    framework instead of software suspend framework. The device
>>>    and CPU state save/restore code of software suspend is called
>>>    when needed.
>>>
>>> 2. The same code path is used for both kexec a new kernel and jump
>>>    back to original kernel.
>>
>> I like the idea but I think I'll let people chat about it a bit more
>> before looking at merging the patches, OK?
>
> Please wait until you see a complete implementation that actually works. I'm
> sitting here quietly, following (and now breaking) the "If you can't say
> anything positive, don't say anything at all" line because I think that the
> more into the implementation details people get, the uglier this is going to
> show itself to be. I'm perfectly willing to be proven wrong, but haven't seen
> anything so far that's even begun to convince me otherwise.

as someone who's eager to have this work, I have to agree with Nigel that 
it's premature to talk about merging anything.

the only exception I could see is if there are other uses for this 
functionality. but even then, let things settle out a little bit.

David Lang


From oomichi at mxs.nes.nec.co.jp  Thu Jul 19 02:14:46 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Thu, 19 Jul 2007 15:14:46 +0900
Subject: [PATCH] [makedumpfile] Introduce -f (force) option
In-Reply-To: <20070717135615.GA19864@suse.de>
References: <20070717135615.GA19864@suse.de>
Message-ID: <20070719151446oomichi@mail.jp.nec.com>


Hi Bernhard,

2007/07/17 15:56:16 +0200, Bernhard Walle <bwalle at suse.de> wrote:
>As I always forget to delete the produced dump file when testing
>something, I'd like to see a `-f' option that forces makedumpfile to
>overwrite existing files.

Thank you for a good patch.
I will merge it into a new release.


Thanks
Ken'ichi Ohmichi

>Signed-off-by: Bernhard Walle <bwalle at suse.de>
>
>---
> makedumpfile.8 |   10 ++++++++++
> makedumpfile.c |   11 +++++++++--
> makedumpfile.h |    1 +
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
>--- a/makedumpfile.8
>+++ b/makedumpfile.8
>@@ -144,6 +144,16 @@ support compressed data.
> # makedumpfile \-E \-d 31 \-x vmlinux /proc/vmcore dumpfile
> 
> .TP
>+\fB\-f\fR
>+Force existing files to be overwritten.
>+.br
>+.B Example:
>+.br
>+# makedumpfile \-f \-x vmlinux /proc/vmcore dumpfile
>+.br
>+This command overwrites \fIdumpfile\fR if it already exists.
>+
>+.TP
> \fB\-x\fR \fIVMLINUX\fR
> Specify the first kernel's \fIVMLINUX\fR with debug information to analyze the
> first kernel's memory usage.
>--- a/makedumpfile.c
>+++ b/makedumpfile.c
>@@ -409,6 +409,10 @@ int
> open_dump_file(struct DumpInfo *info)
> {
> 	int fd;
>+	int open_flags = O_RDWR|O_CREAT;
>+
>+	if (!info->flag_force)
>+		open_flags |= O_EXCL;
> 
> 	if (info->flag_flatten) {
> 		if ((info->name_dumpfile
>@@ -420,7 +424,7 @@ open_dump_file(struct DumpInfo *info)
> 		fd = STDOUT_FILENO;
> 		strcpy(info->name_dumpfile, FILENAME_STDOUT);
> 
>-	} else if ((fd = open(info->name_dumpfile, O_RDWR|O_CREAT|O_EXCL,
>+	} else if ((fd = open(info->name_dumpfile, open_flags,
> 	    S_IRUSR|S_IWUSR)) < 0) {
> 		ERRMSG("Can't open the dump file(%s). %s\n",
> 		    info->name_dumpfile, strerror(errno));
>@@ -4624,7 +4628,7 @@ main(int argc, char *argv[])
> 	vt = &info->vm_table;
> 
> 	info->block_order = DEFAULT_ORDER;
>-	while ((opt = getopt(argc, argv, "b:cDd:EFg:hi:Rvx:")) != -1) {
>+	while ((opt = getopt(argc, argv, "b:cDd:EFg:hi:Rvx:f")) != -1) {
> 		switch (opt) {
> 		case 'b':
> 			info->block_order = atoi(optarg);
>@@ -4646,6 +4650,9 @@ main(int argc, char *argv[])
> 		case 'F':
> 			info->flag_flatten = 1;
> 			break;
>+		case 'f':
>+			info->flag_force = 1;
>+			break;
> 		case 'g':
> 			info->flag_generate_config = 1;
> 			info->name_configfile = optarg;
>--- a/makedumpfile.h
>+++ b/makedumpfile.h
>@@ -552,6 +552,7 @@ struct DumpInfo {
> 						format to a standard out */
> 	int		flag_rearrange;      /* flag of creating dumpfile from
> 						flattened format */
>+	int		flag_force;	     /* overwrite existing stuff */
> 	long		page_size;           /* size of page */
> 	long		page_shift;
> 	unsigned long long	max_mapnr;   /* number of page descriptor */
>
>_______________________________________________
>kexec mailing list
>kexec at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec


From ying.huang at intel.com  Thu Jul 19 02:43:23 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Thu, 19 Jul 2007 14:43:23 +0800
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <20070718180420.02352d4f.akpm@linux-foundation.org>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070718180420.02352d4f.akpm@linux-foundation.org>
Message-ID: <1184827403.15756.14.camel@caritas-dev.intel.com>

On Wed, 2007-07-18 at 18:04 -0700, Andrew Morton wrote:
> I like the idea but I think I'll let people chat about it a bit more
> before looking at merging the patches, OK?

I think maybe we should wait for Rafael to separate the device hibernate
(quiesce and state save) from device suspend. Without that, the ACPI
issue can not be resolved.

Best Regards,
Huang Ying


From rjw at sisk.pl  Thu Jul 19 05:13:21 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Thu, 19 Jul 2007 11:13:21 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184827403.15756.14.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070718180420.02352d4f.akpm@linux-foundation.org>
	<1184827403.15756.14.camel@caritas-dev.intel.com>
Message-ID: <200707191113.22711.rjw@sisk.pl>

On Thursday, 19 July 2007 08:43, Huang, Ying wrote:
> On Wed, 2007-07-18 at 18:04 -0700, Andrew Morton wrote:
> > I like the idea but I think I'll let people chat about it a bit more
> > before looking at merging the patches, OK?
> 
> I think maybe we should wait for Rafael to separate the device hibernate
> (quiesce and state save) from device suspend.

Well, I'm afraid that will take some time ...

> Without that, the ACPI issue can not be resolved.

Yes, it seems so.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From t-nagano at ah.jp.nec.com  Thu Jul 19 08:15:12 2007
From: t-nagano at ah.jp.nec.com (Takenori Nagano)
Date: Thu, 19 Jul 2007 21:15:12 +0900
Subject: [patch] add kdump_after_notifier
Message-ID: <469F55D0.4050203@ah.jp.nec.com>

Hi,

In latest kernel, we can't use panic_notifier_list if kdump is enabled.
panic_notifier_list is very useful function for debug, failover, etc...

So this patch adds a control file /proc/sys/kernel/dump_after_notifier
and resolves a problem users can not use both kdump and panic_notifier_list
at the same time.

kdump_after_notifier = 0
 -> panic()
    -> crash_kexec(NULL)

kdump_after_notifier = 1
 -> panic()
    -> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
    -> crash_kexec(NULL)


Signed-off-by: Takenori Nagano <t-nagano at ah.jp.nec.com>
Signed-off-by: Kazuto Miyoshi <k-miyoshi at cb.jp.nec.com>
---

diff -uprN linux-2.6.22.orig/include/linux/kexec.h
linux-2.6.22/include/linux/kexec.h
--- linux-2.6.22.orig/include/linux/kexec.h	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/include/linux/kexec.h	2007-07-19 18:55:04.236000000 +0900
@@ -123,6 +123,7 @@ int kexec_should_crash(struct task_struc
 void crash_save_cpu(struct pt_regs *regs, int cpu);
 extern struct kimage *kexec_image;
 extern struct kimage *kexec_crash_image;
+extern int kdump_after_notifier;

 #ifndef kexec_flush_icache_page
 #define kexec_flush_icache_page(page)
@@ -160,5 +161,6 @@ struct pt_regs;
 struct task_struct;
 static inline void crash_kexec(struct pt_regs *regs) { }
 static inline int kexec_should_crash(struct task_struct *p) { return 0; }
+#define kdump_after_notifier 0
 #endif /* CONFIG_KEXEC */
 #endif /* LINUX_KEXEC_H */
diff -uprN linux-2.6.22.orig/include/linux/sysctl.h
linux-2.6.22/include/linux/sysctl.h
--- linux-2.6.22.orig/include/linux/sysctl.h	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/include/linux/sysctl.h	2007-07-19 18:55:04.260000000 +0900
@@ -165,6 +165,7 @@ enum
 	KERN_MAX_LOCK_DEPTH=74,
 	KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
 	KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
+	KERN_KDUMP_AFTER_NOTIFIER=77, /* int: kdump after panic_notifier */
 };


diff -uprN linux-2.6.22.orig/kernel/kexec.c linux-2.6.22/kernel/kexec.c
--- linux-2.6.22.orig/kernel/kexec.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/kernel/kexec.c	2007-07-19 18:55:04.304000000 +0900
@@ -22,6 +22,7 @@
 #include <linux/hardirq.h>
 #include <linux/elf.h>
 #include <linux/elfcore.h>
+#include <linux/sysctl.h>

 #include <asm/page.h>
 #include <asm/uaccess.h>
@@ -31,6 +32,7 @@

 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t* crash_notes;
+int kdump_after_notifier;

 /* Location of the reserved area for the crash kernel */
 struct resource crashk_res = {
@@ -1123,6 +1125,30 @@ void crash_save_cpu(struct pt_regs *regs
 	final_note(buf);
 }

+#ifdef CONFIG_SYSCTL
+static ctl_table kdump_after_notifier_table[] = {
+	{
+		.ctl_name = KERN_KDUMP_AFTER_NOTIFIER,
+		.procname = "kdump_after_notifier",
+		.data = &kdump_after_notifier,
+		.maxlen = sizeof(int),
+		.mode = 0644,
+		.proc_handler = &proc_dointvec,
+	},
+	{ .ctl_name = 0 }
+};
+
+static ctl_table kexec_sys_table[] = {
+	{
+		.ctl_name = CTL_KERN,
+		.procname = "kernel",
+		.mode = 0555,
+		.child = kdump_after_notifier_table,
+	},
+	{ .ctl_name = 0 }
+};
+#endif
+
 static int __init crash_notes_memory_init(void)
 {
 	/* Allocate memory for saving cpu registers. */
@@ -1132,6 +1158,9 @@ static int __init crash_notes_memory_ini
 		" states failed\n");
 		return -ENOMEM;
 	}
+#ifdef CONFIG_SYSCTL
+	register_sysctl_table(kexec_sys_table, 0);
+#endif
 	return 0;
 }
 module_init(crash_notes_memory_init)
diff -uprN linux-2.6.22.orig/kernel/panic.c linux-2.6.22/kernel/panic.c
--- linux-2.6.22.orig/kernel/panic.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/kernel/panic.c	2007-07-19 18:55:04.340000000 +0900
@@ -85,7 +85,8 @@ NORET_TYPE void panic(const char * fmt,
 	 * everything else.
 	 * Do we want to call this before we try to display a message?
 	 */
-	crash_kexec(NULL);
+	if (!kdump_after_notifier)
+		crash_kexec(NULL);

 #ifdef CONFIG_SMP
 	/*
@@ -98,6 +99,8 @@ NORET_TYPE void panic(const char * fmt,

 	atomic_notifier_call_chain(&panic_notifier_list, 0, buf);

+	crash_kexec(NULL);
+
 	if (!panic_blink)
 		panic_blink = no_blink;





From vgoyal at in.ibm.com  Thu Jul 19 10:12:48 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Thu, 19 Jul 2007 19:42:48 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070718230740oomichi@mail.jp.nec.com>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
Message-ID: <20070719141248.GA18586@in.ibm.com>

On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> 2007/07/16 18:06:33 +0530, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> >On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
> >> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-16 14:25]:
> >> > 
> >> > Ok. Now there seems to be two ways for accessing such info.
> >> > - Through global variables
> >> > - Export through ELF notes.
> >> > 
> >> > Personally, I like the approach taken by Dan Aloni of exporting required
> >> > info through ELF notes. That seems to be more standard in the sense we 
> >> > are not dependent on somebody removing above variable tomorrow.
> >> > 
> >> > Dan, are you planning to put the modified patch for discussions on LKML?
> >> 
> >> You mean the proposal with the makedumpfile-compatible ELF note?
> >> Although I like that idea, I think Ken'ichi Ohmichi was against it.
> >> 
> >
> >Yes, makedumpfile compatible ELF note one. Ken'ichi did not like the idea
> >too much, but I am not sure we discussed his objections in detail. I had
> >also responded with a mail with some of the advantages of ELF note based
> >approach. No response on that.
> 
> Sorry for my delayed response, I took a short vacation.
> 
> I'm not against with the proposal adding PT_NOTE segment to /proc/vmcore.
> I don't like only point that adds the necessary information list
> (some symbols, structures, etc.) for makedumpfile to kernel code.
> 
> The content of mkdfinfo file has been increasing whenever adding
> features and correcting bugs. The content is increasing even now.
> And, the feature addition is done not only for new kernels but also
> for old upstream kernels. When the content of mkdfinfo file is taken 
> into the kernel and fixed, the feature addition in the future is
> remarkably limited. So makedumpfile needs mkdfinfo file outside of
> the kernel.
> 

Well, idea of filtering tool having flexibility to create its own ELF note
and later retrieve it and use it looks good. But at the same time you 
will have to standardize the contents of ELF note. One can not keep on
changing it at will.

> I propose the solution including Dan's, Vivek's and Bernhard's opinions.
> How about the following sequence for distributors ?
> (It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
>  A new option "--mkdfinfo" is added to kexec command.)
> 
> * On the kernel building system
>   1. Create the kernel files.
>      # cd linux-2.6.xx
>      # make
>   2. Create the mkdfinfo file from the vmlinux.
>      # makedumpfile -g mkdfinfo-2.6.xx -x vmlinux
>      (OSRELEASE is taken from the vmlinux.)
>   3. Pack the kernel package with the kernel files and the mkdfinfo file.
> 
> * On each system
>   4. Preload 2nd-kernel and the mkdfinfo file.
>      # kexec -p vmlinux-kdump --mkdfinfo=mkdfinfo-2.6.xx ...

Providing first kernel's debug data on commandline while loading second
kernel is little odd but I guess can be lived with.

>      - 2nd-kernel is preloaded.
>      - 1st-kernel's PAGESIZE is taken by sysconf().
>      - The mkdfinfo file and the above PAGESIZE is preloaded
>        into /proc/vmcore's PT_NOTE segment.

>   5. Panic happens, and the system switchs to 2nd-kernel.
>   6. Create a filtered dump file.
>      # makedumpfile -cd31 /proc/vmcore dumpfile
>      (User doesn't need to specify the mkdfinfo file, because the
>       contents of the mkdfinfo file is included into /proc/vmcore.)
> 

Overall proposal looks interesting. But it still requires a debug compiled
vmlinux for one to use filtering. For distros it is probably easy as they
can extract the debug info at build time and ship separate file with kernel
package (/boot/mkdfinfo-2.6.xxx). For people building their custom kernel,
they still need to build vmlinux with debuginfo. Personally, I wished
we could get rid of this requirement. I think may be down the line we can
start exporting it from kenrel once contents of ELF note are well defined.

Thanks
Vivek





From dzickus at redhat.com  Thu Jul 19 12:39:15 2007
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 19 Jul 2007 12:39:15 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070718230740oomichi@mail.jp.nec.com>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
Message-ID: <20070719163915.GN9623@redhat.com>

On Wed, Jul 18, 2007 at 11:07:40PM +0900, Ken'ichi Ohmichi wrote:
> The content of mkdfinfo file has been increasing whenever adding
> features and correcting bugs. The content is increasing even now.
> And, the feature addition is done not only for new kernels but also
> for old upstream kernels. When the content of mkdfinfo file is taken 
> into the kernel and fixed, the feature addition in the future is
> remarkably limited. So makedumpfile needs mkdfinfo file outside of
> the kernel.
> 
> I propose the solution including Dan's, Vivek's and Bernhard's opinions.
> How about the following sequence for distributors ?
> (It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
>  A new option "--mkdfinfo" is added to kexec command.)
> 
> * On the kernel building system
>   1. Create the kernel files.
>      # cd linux-2.6.xx
>      # make
>   2. Create the mkdfinfo file from the vmlinux.
>      # makedumpfile -g mkdfinfo-2.6.xx -x vmlinux

I am not a big fan of this approach as it forces distros to require
kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
kernel (and not interested in kexec) would have to not only download the
kernel.src.rpm but kexec-tools just to build a kernel that probably
doesn't have kexec enabled.

I had to deal with a similar experience when providing a build dependency
on the unifdef package when create the kernel-headers rpm for RHEL-5.  A
lot of people were confused and upset by this dependency.  Luckily
upstream resolved this by just putting similar code in the kernel/scripts
directory and thus removing the dependency (well not for RHEL-5).  I would
rather not have to deal with this again unless I know there is a more
permanent solution that would remove this dependency.

After talking to Dave Anderson about this more, I start to understand why
Ken'ichi prefers to implement the new features in userspace instead of the
kernel (it makes things automatically work with older kernels), but I
still am not a big fan of it.  I was hoping for a complete in kernel
solution (that way you never need the vmlinux file).  Perhaps makedumpfile
can support both vmlinux files (if provided) or interface with the kernel
(if the vmlinux is not provided?).

Just my input.  I might as well argue with Ken'ichi here than the
bugzilla. :-)

Cheers,
Don


From bwalle at suse.de  Thu Jul 19 12:49:53 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 19 Jul 2007 18:49:53 +0200
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070719163915.GN9623@redhat.com>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
	<20070719163915.GN9623@redhat.com>
Message-ID: <20070719164953.GA5381@suse.de>

* Don Zickus <dzickus at redhat.com> [2007-07-19 18:39]:
> 
> I am not a big fan of this approach as it forces distros to require
> kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
> kernel (and not interested in kexec) would have to not only download the
> kernel.src.rpm but kexec-tools just to build a kernel that probably
> doesn't have kexec enabled.

He would have to download makedumpfile, not kexec-tools.


Thanks,
   Bernhard


From dzickus at redhat.com  Thu Jul 19 12:59:32 2007
From: dzickus at redhat.com (Don Zickus)
Date: Thu, 19 Jul 2007 12:59:32 -0400
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070719164953.GA5381@suse.de>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
	<20070719163915.GN9623@redhat.com> <20070719164953.GA5381@suse.de>
Message-ID: <20070719165932.GO9623@redhat.com>

On Thu, Jul 19, 2007 at 06:49:53PM +0200, Bernhard Walle wrote:
> * Don Zickus <dzickus at redhat.com> [2007-07-19 18:39]:
> > 
> > I am not a big fan of this approach as it forces distros to require
> > kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
> > kernel (and not interested in kexec) would have to not only download the
> > kernel.src.rpm but kexec-tools just to build a kernel that probably
> > doesn't have kexec enabled.
> 
> He would have to download makedumpfile, not kexec-tools.

My apologies.  Red Hat packages makedumpfile under kexec-tools, hence my
confusion.

Cheers,
Don


From fernando at oss.ntt.co.jp  Thu Jul 19 21:54:19 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Fri, 20 Jul 2007 10:54:19 +0900
Subject: [PATCH RFC] Debug handling of early spurious interrupts
In-Reply-To: <20070718154659.c8b5ffea.akpm@linux-foundation.org>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
Message-ID: <1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>

On Wed, 2007-07-18 at 15:46 -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2007 19:09:57 +0900
> Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:
> 
> > With the advent of kdump it is possible that device drivers receive
> > interrupts generated in the context of a previous kernel. Ideally
> > quiescing the underlying devices should suffice but not all drivers
> > do this, either because it is not possible or because they did not
> > contemplate this case. Thus drivers ought to be able to handle
> > interrupts coming in as soon as the interrupt handler is registered.
> > 
> > Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
> > ---
> > 
> > diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22/kernel/irq/manage.c
> > --- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-09 08:32:17.000000000 +0900
> > +++ linux-2.6.22/kernel/irq/manage.c	2007-07-17 18:37:24.000000000 +0900
> > @@ -537,6 +537,29 @@ int request_irq(unsigned int irq, irq_ha
> >  
> >  	select_smp_affinity(irq);
> >  
> > +#if defined(CONFIG_DEBUG_PENDING_IRQ) || defined(CONFIG_DEBUG_SHIRQ)
> > +#ifndef CONFIG_DEBUG_PENDING_IRQ
> > +	if (irqflags & IRQF_SHARED) {
> > +		/*
> > +		 * It's a shared IRQ -- the driver ought to be prepared for it
> > +		 * to happen immediately, so let's make sure....
> > +		 * We do this before actually registering it, to make sure that
> > +		 * a 'real' IRQ doesn't run in parallel with our fake.
> > +		 */
> > +#endif /* !CONFIG_DEBUG_PENDING_IRQ */
> > +		if (irqflags & IRQF_DISABLED) {
> > +			unsigned long flags;
> > +
> > +			local_irq_save(flags);
> > +			handler(irq, dev_id);
> > +			local_irq_restore(flags);
> > +		} else
> > +			handler(irq, dev_id);
> > +#ifndef CONFIG_DEBUG_PENDING_IRQ
> > +	}
> > +#endif /* !CONFIG_DEBUG_PENDING_IRQ */
> > +#endif /* CONFIG_DEBUG_PENDING_IRQ || CONFIG_DEBUG_SHIRQ */
> 
> Even if we were going to merge this functionality as-is, I'd ask for some
> sort of refactoring to fix up that ifdef maze.
I a absolutely agree. My first impulse was to get rid of all the cpp
kludge including the Kconfig setting CONFIG_DEBUG_SHIRQ, since, as you
pointed out, request_irq() is not really performance critical.
Unfortunately for the RFC I decided to be conservative and ended up with
an "ifdef maze". Thank you for the heads-up.

> But more substantial issues:
> 
> - This is presented as a "debug" feature, but it isn't a debug feature at
>   all - it is new functionality which is unrelated to kernel development.
Yup.

>   Also, it is a "debug" feature which provides no debugging!  At the very
>   least, one would expect to see it emit a printk to tell people that we
>   have some driver which needs fixing.
I am afraid that in some occasions the kernel may panic inside the
interrupt handler, but I agree that we need to print a meaningful
message for the general case (i.e. something goes wrong but we can
recover). I will do that.

>   Also, this not-really-a-debug-feature is undesirably coupled with a
>   real debugging feature: CONFIG_DEBUG_PENDING_IRQ.
In the new version of the patch I will remove both
CONFIG_DEBUG_PENDING_IRQ and CONFIG_DEBUG_SHIRQ. request_irq() and
setup_irq() are not fast paths and free_irq() much less so.

> - Does this new feature really need its own Kconfig setting?  Why not enable
>   it unconditionally?  request_irq() isn't exactly performance-critical.
I guess the Kconfig setting is not needed. In fact, by enabling this
feature unconditionally we would have _everyone_ (unknowing) testing an
area which is a major pain point for kdump. I am not sure this is an
acceptable default for all systems though. Opinions welcome.

> - If poss, we really do want to find some way of emitting a warning when
>   we detect such a device driver.  Like, call the handler and if it
>   returned IRQ_HANDLED, start shouting.
I will do that and submit updated patches.

Thank you for your feedback, Andrew!



From akpm at linux-foundation.org  Fri Jul 20 17:43:02 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Fri, 20 Jul 2007 14:43:02 -0700
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
	<1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <20070720144302.2785e961.akpm@linux-foundation.org>

On Fri, 20 Jul 2007 11:20:43 +0900
Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:

> With the advent of kdump it is possible that device drivers receive
> interrupts generated in the context of a previous kernel. Ideally
> quiescing the underlying devices should suffice but not all drivers do
> this, either because it is not possible or because they did not
> contemplate this case. Thus drivers ought to be able to handle
> interrupts coming in as soon as the interrupt handler is registered.
> 
> Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
> ---
> 
> diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22-pendirq/kernel/irq/manage.c
> --- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-19 18:18:53.000000000 +0900
> +++ linux-2.6.22-pendirq/kernel/irq/manage.c	2007-07-19 19:43:41.000000000 +0900
> @@ -533,21 +533,32 @@ int request_irq(unsigned int irq, irq_ha
>  
>  	select_smp_affinity(irq);
>  
> -	if (irqflags & IRQF_SHARED) {
> -		/*
> -		 * It's a shared IRQ -- the driver ought to be prepared for it
> -		 * to happen immediately, so let's make sure....
> -		 * We do this before actually registering it, to make sure that
> -		 * a 'real' IRQ doesn't run in parallel with our fake
> -		 */
> -		if (irqflags & IRQF_DISABLED) {
> -			unsigned long flags;
> +	/*
> +	 * With the advent of kdump it possible that device drivers receive
> +	 * interrupts generated in the context of a previous kernel. Ideally
> +	 * quiescing the underlying devices should suffice but not all drivers
> +	 * do this, either because it is not possible or because they did not
> +	 * contemplate this case. Thus drivers ought to be able to handle
> +	 * interrupts coming in as soon as the interrupt handler is registered.
> +	 *
> +	 * Besides, if it is a shared IRQ the driver ought to be prepared for
> +	 * it to happen immediately too.
> +	 *
> +	 * We do this before actually registering it, to make sure that
> +	 * a 'real' IRQ doesn't run in parallel with our fake.
> +	 */
> +	if (irqflags & IRQF_DISABLED) {
> +		unsigned long flags;
>  
> -			local_irq_save(flags);
> -			handler(irq, dev_id);
> -			local_irq_restore(flags);
> -		} else
> -			handler(irq, dev_id);
> +		local_irq_save(flags);
> +		retval = handler(irq, dev_id);
> +		local_irq_restore(flags);
> +	} else
> +		retval = handler(irq, dev_id);
> +	if (retval == IRQ_HANDLED) {
> +		printk(KERN_WARNING
> +		       "%s (IRQ %d) handled a spurious interrupt\n",
> +		       devname, irq);
>  	}
>  

This change means that we'll run the irq handler at request_irq()-time even
for non-shared interrupts.

This is a bit of a worry.  See, shared-interrupt handlers are required to
be able to cope with being called when their device isn't interrupting. 
But nobody ever said that non-shared interrupt handlers need to be able to
cope with that.

Hence these non-shared handlers are within their rights to emit warning
printks, go BUG or accuse the operator of having busted hardware.

So bad things might happen because of this change.  And if they do, they
will take a loooong time to be discovered, because non-shared interrupt
handlers tend to dwell in crufty old drivers which not many people use.

So I'm wondering if it would be more prudent to only do all this for shared
handlers?




From fernando at oss.ntt.co.jp  Thu Jul 19 22:02:24 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Fri, 20 Jul 2007 11:02:24 +0900
Subject: [PATCH 1/2] Remove Kconfig setting CONFIG_DEBUG_SHIRQ
In-Reply-To: <1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>

request_irq() and setup_irq() are not fast paths and free_irq() much
less so. In fact, by enabling this feature unconditionally we would have
_everyone_ (unknowingly) testing devices drivers, which hopefully will
result in more bug-reports and, in turn, better drivers.

Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
---

diff -urNp linux-2.6.22-orig/arch/arm/configs/at91sam9rlek_defconfig linux-2.6.22-pendirq/arch/arm/configs/at91sam9rlek_defconfig
--- linux-2.6.22-orig/arch/arm/configs/at91sam9rlek_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/arm/configs/at91sam9rlek_defconfig	2007-07-19 16:49:54.000000000 +0900
@@ -906,7 +906,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # 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=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/arm/configs/picotux200_defconfig linux-2.6.22-pendirq/arch/arm/configs/picotux200_defconfig
--- linux-2.6.22-orig/arch/arm/configs/picotux200_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/arm/configs/picotux200_defconfig	2007-07-19 16:50:00.000000000 +0900
@@ -1293,7 +1293,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # 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=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/arm/configs/s3c2410_defconfig linux-2.6.22-pendirq/arch/arm/configs/s3c2410_defconfig
--- linux-2.6.22-orig/arch/arm/configs/s3c2410_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/arm/configs/s3c2410_defconfig	2007-07-19 16:50:06.000000000 +0900
@@ -1368,7 +1368,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=16
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/avr32/configs/atngw100_defconfig linux-2.6.22-pendirq/arch/avr32/configs/atngw100_defconfig
--- linux-2.6.22-orig/arch/avr32/configs/atngw100_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/avr32/configs/atngw100_defconfig	2007-07-19 16:50:11.000000000 +0900
@@ -925,7 +925,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/avr32/configs/atstk1002_defconfig linux-2.6.22-pendirq/arch/avr32/configs/atstk1002_defconfig
--- linux-2.6.22-orig/arch/avr32/configs/atstk1002_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/avr32/configs/atstk1002_defconfig	2007-07-19 16:50:16.000000000 +0900
@@ -756,7 +756,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/i386/defconfig linux-2.6.22-pendirq/arch/i386/defconfig
--- linux-2.6.22-orig/arch/i386/defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/i386/defconfig	2007-07-19 16:50:21.000000000 +0900
@@ -1424,7 +1424,6 @@ CONFIG_UNUSED_SYMBOLS=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/ia64/configs/tiger_defconfig linux-2.6.22-pendirq/arch/ia64/configs/tiger_defconfig
--- linux-2.6.22-orig/arch/ia64/configs/tiger_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/ia64/configs/tiger_defconfig	2007-07-19 16:50:26.000000000 +0900
@@ -1318,7 +1318,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=20
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/ia64/configs/zx1_defconfig linux-2.6.22-pendirq/arch/ia64/configs/zx1_defconfig
--- linux-2.6.22-orig/arch/ia64/configs/zx1_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/ia64/configs/zx1_defconfig	2007-07-19 16:50:31.000000000 +0900
@@ -1533,7 +1533,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=17
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/ia64/defconfig linux-2.6.22-pendirq/arch/ia64/defconfig
--- linux-2.6.22-orig/arch/ia64/defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/ia64/defconfig	2007-07-19 16:50:36.000000000 +0900
@@ -1482,7 +1482,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=20
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/mips/configs/bigsur_defconfig linux-2.6.22-pendirq/arch/mips/configs/bigsur_defconfig
--- linux-2.6.22-orig/arch/mips/configs/bigsur_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/mips/configs/bigsur_defconfig	2007-07-19 16:50:42.000000000 +0900
@@ -1003,7 +1003,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=16
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/mips/configs/mipssim_defconfig linux-2.6.22-pendirq/arch/mips/configs/mipssim_defconfig
--- linux-2.6.22-orig/arch/mips/configs/mipssim_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/mips/configs/mipssim_defconfig	2007-07-19 16:50:54.000000000 +0900
@@ -855,7 +855,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_UNUSED_SYMBOLS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_LOG_BUF_SHIFT=14
 # CONFIG_DETECT_SOFTLOCKUP is not set
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/mips/configs/pnx8550-jbs_defconfig linux-2.6.22-pendirq/arch/mips/configs/pnx8550-jbs_defconfig
--- linux-2.6.22-orig/arch/mips/configs/pnx8550-jbs_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/mips/configs/pnx8550-jbs_defconfig	2007-07-19 16:51:08.000000000 +0900
@@ -1205,7 +1205,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/mips/configs/pnx8550-stb810_defconfig linux-2.6.22-pendirq/arch/mips/configs/pnx8550-stb810_defconfig
--- linux-2.6.22-orig/arch/mips/configs/pnx8550-stb810_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/mips/configs/pnx8550-stb810_defconfig	2007-07-19 16:51:33.000000000 +0900
@@ -1195,7 +1195,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 CONFIG_HEADERS_CHECK=y
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/mips/configs/yosemite_defconfig linux-2.6.22-pendirq/arch/mips/configs/yosemite_defconfig
--- linux-2.6.22-orig/arch/mips/configs/yosemite_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/mips/configs/yosemite_defconfig	2007-07-19 16:51:38.000000000 +0900
@@ -816,7 +816,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # 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=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/cell_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/cell_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/cell_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/cell_defconfig	2007-07-19 16:51:59.000000000 +0900
@@ -1468,7 +1468,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 # CONFIG_DETECT_SOFTLOCKUP is not set
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/celleb_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/celleb_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/celleb_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/celleb_defconfig	2007-07-19 16:52:06.000000000 +0900
@@ -1295,7 +1295,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/chrp32_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/chrp32_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/chrp32_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/chrp32_defconfig	2007-07-19 16:52:12.000000000 +0900
@@ -1454,7 +1454,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/ebony_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/ebony_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/ebony_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/ebony_defconfig	2007-07-19 16:52:16.000000000 +0900
@@ -772,7 +772,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/g5_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/g5_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/g5_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/g5_defconfig	2007-07-19 16:52:22.000000000 +0900
@@ -1645,7 +1645,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/holly_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/holly_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/holly_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/holly_defconfig	2007-07-19 16:52:26.000000000 +0900
@@ -985,7 +985,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/iseries_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/iseries_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/iseries_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/iseries_defconfig	2007-07-19 16:52:30.000000000 +0900
@@ -1147,7 +1147,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/linkstation_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/linkstation_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/linkstation_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/linkstation_defconfig	2007-07-19 16:52:34.000000000 +0900
@@ -1530,7 +1530,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/lite5200_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/lite5200_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/lite5200_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/lite5200_defconfig	2007-07-19 16:52:38.000000000 +0900
@@ -893,7 +893,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/maple_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/maple_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/maple_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/maple_defconfig	2007-07-19 16:52:43.000000000 +0900
@@ -1169,7 +1169,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8272_ads_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8272_ads_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8272_ads_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8272_ads_defconfig	2007-07-19 16:52:47.000000000 +0900
@@ -844,7 +844,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8313_rdb_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8313_rdb_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8313_rdb_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8313_rdb_defconfig	2007-07-19 16:52:51.000000000 +0900
@@ -1336,7 +1336,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8540_ads_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8540_ads_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8540_ads_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8540_ads_defconfig	2007-07-19 16:52:56.000000000 +0900
@@ -772,7 +772,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8544_ds_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8544_ds_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8544_ds_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8544_ds_defconfig	2007-07-19 16:53:00.000000000 +0900
@@ -963,7 +963,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8560_ads_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8560_ads_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8560_ads_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8560_ads_defconfig	2007-07-19 16:53:04.000000000 +0900
@@ -852,7 +852,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8568mds_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8568mds_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8568mds_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8568mds_defconfig	2007-07-19 16:53:08.000000000 +0900
@@ -890,7 +890,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc85xx_cds_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc85xx_cds_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc85xx_cds_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc85xx_cds_defconfig	2007-07-19 16:53:11.000000000 +0900
@@ -905,7 +905,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/mpc8641_hpcn_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/mpc8641_hpcn_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/mpc8641_hpcn_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/mpc8641_hpcn_defconfig	2007-07-19 16:53:15.000000000 +0900
@@ -962,7 +962,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/pasemi_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/pasemi_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/pasemi_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/pasemi_defconfig	2007-07-19 16:53:27.000000000 +0900
@@ -1646,7 +1646,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/pmac32_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/pmac32_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/pmac32_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/pmac32_defconfig	2007-07-19 16:53:30.000000000 +0900
@@ -1885,7 +1885,6 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/ppc64_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/ppc64_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/ppc64_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/ppc64_defconfig	2007-07-19 16:53:34.000000000 +0900
@@ -1801,7 +1801,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/ps3_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/ps3_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/ps3_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/ps3_defconfig	2007-07-19 16:53:40.000000000 +0900
@@ -1091,7 +1091,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/powerpc/configs/pseries_defconfig linux-2.6.22-pendirq/arch/powerpc/configs/pseries_defconfig
--- linux-2.6.22-orig/arch/powerpc/configs/pseries_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/powerpc/configs/pseries_defconfig	2007-07-19 16:54:16.000000000 +0900
@@ -1580,7 +1580,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/sh/configs/r7780rp_defconfig linux-2.6.22-pendirq/arch/sh/configs/r7780rp_defconfig
--- linux-2.6.22-orig/arch/sh/configs/r7780rp_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/sh/configs/r7780rp_defconfig	2007-07-19 16:54:27.000000000 +0900
@@ -1235,7 +1235,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/sh/configs/r7785rp_defconfig linux-2.6.22-pendirq/arch/sh/configs/r7785rp_defconfig
--- linux-2.6.22-orig/arch/sh/configs/r7785rp_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/sh/configs/r7785rp_defconfig	2007-07-19 16:54:31.000000000 +0900
@@ -1238,7 +1238,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_LOG_BUF_SHIFT=14
 # CONFIG_DETECT_SOFTLOCKUP is not set
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/sh/configs/se7712_defconfig linux-2.6.22-pendirq/arch/sh/configs/se7712_defconfig
--- linux-2.6.22-orig/arch/sh/configs/se7712_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/sh/configs/se7712_defconfig	2007-07-19 16:54:34.000000000 +0900
@@ -993,7 +993,6 @@ CONFIG_ENABLE_MUST_CHECK=y
 # 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=14
 # CONFIG_DETECT_SOFTLOCKUP is not set
 # CONFIG_SCHEDSTATS is not set
diff -urNp linux-2.6.22-orig/arch/sh64/configs/cayman_defconfig linux-2.6.22-pendirq/arch/sh64/configs/cayman_defconfig
--- linux-2.6.22-orig/arch/sh64/configs/cayman_defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/sh64/configs/cayman_defconfig	2007-07-19 16:54:22.000000000 +0900
@@ -999,7 +999,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 CONFIG_SCHEDSTATS=y
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/sparc64/defconfig linux-2.6.22-pendirq/arch/sparc64/defconfig
--- linux-2.6.22-orig/arch/sparc64/defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/sparc64/defconfig	2007-07-19 16:54:38.000000000 +0900
@@ -1463,7 +1463,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 CONFIG_SCHEDSTATS=y
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/arch/x86_64/defconfig linux-2.6.22-pendirq/arch/x86_64/defconfig
--- linux-2.6.22-orig/arch/x86_64/defconfig	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/arch/x86_64/defconfig	2007-07-19 16:54:43.000000000 +0900
@@ -1522,7 +1522,6 @@ CONFIG_UNUSED_SYMBOLS=y
 CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
 CONFIG_DETECT_SOFTLOCKUP=y
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
diff -urNp linux-2.6.22-orig/drivers/char/cyclades.c linux-2.6.22-pendirq/drivers/char/cyclades.c
--- linux-2.6.22-orig/drivers/char/cyclades.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/drivers/char/cyclades.c	2007-07-19 17:11:48.000000000 +0900
@@ -1408,7 +1408,7 @@ static irqreturn_t cyy_interrupt(int irq
 	card_base_addr = cinfo->base_addr;
 	index = cinfo->bus_index;
 
-	/* card was not initialized yet (e.g. DEBUG_SHIRQ) */
+	/* card was not initialized yet (e.g. shared IRQ) */
 	if (unlikely(card_base_addr == NULL))
 		return IRQ_HANDLED;
 
diff -urNp linux-2.6.22-orig/drivers/net/e1000/e1000_main.c linux-2.6.22-pendirq/drivers/net/e1000/e1000_main.c
--- linux-2.6.22-orig/drivers/net/e1000/e1000_main.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/drivers/net/e1000/e1000_main.c	2007-07-19 17:23:55.000000000 +0900
@@ -1424,10 +1424,11 @@ e1000_open(struct net_device *netdev)
 	    e1000_check_mng_mode(&adapter->hw))
 		e1000_get_hw_control(adapter);
 
-	/* before we allocate an interrupt, we must be ready to handle it.
-	 * Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
-	 * as soon as we call pci_request_irq, so we have to setup our
-	 * clean_rx handler before we do so.  */
+	/* Before we allocate an interrupt, we must be ready to handle it.
+	 * Any pending interrupts (coming from a device sharing our IRQ line or
+	 * generated in the context of a previous kernel if this is a kdump
+	 * kernel, for example) will come in as soon as we call pci_request_irq,
+	 * so we have to setup our clean_rx handler before we do so.  */
 	e1000_configure(adapter);
 
 	err = e1000_request_irq(adapter);
diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22-pendirq/kernel/irq/manage.c
--- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/kernel/irq/manage.c	2007-07-19 17:04:50.000000000 +0900
@@ -374,14 +374,12 @@ int setup_irq(unsigned int irq, struct i
 	return 0;
 
 mismatch:
-#ifdef CONFIG_DEBUG_SHIRQ
 	if (!(new->flags & IRQF_PROBE_SHARED)) {
 		printk(KERN_ERR "IRQ handler type mismatch for IRQ %d\n", irq);
 		if (old_name)
 			printk(KERN_ERR "current handler: %s\n", old_name);
 		dump_stack();
 	}
-#endif
 	spin_unlock_irqrestore(&desc->lock, flags);
 	return -EBUSY;
 }
@@ -454,7 +452,6 @@ void free_irq(unsigned int irq, void *de
 		spin_unlock_irqrestore(&desc->lock, flags);
 		return;
 	}
-#ifdef CONFIG_DEBUG_SHIRQ
 	if (handler) {
 		/*
 		 * It's a shared IRQ -- the driver ought to be prepared for it
@@ -464,7 +461,6 @@ void free_irq(unsigned int irq, void *de
 		 */
 		handler(irq, dev_id);
 	}
-#endif
 }
 EXPORT_SYMBOL(free_irq);
 
@@ -537,7 +533,6 @@ int request_irq(unsigned int irq, irq_ha
 
 	select_smp_affinity(irq);
 
-#ifdef CONFIG_DEBUG_SHIRQ
 	if (irqflags & IRQF_SHARED) {
 		/*
 		 * It's a shared IRQ -- the driver ought to be prepared for it
@@ -554,7 +549,6 @@ int request_irq(unsigned int irq, irq_ha
 		} else
 			handler(irq, dev_id);
 	}
-#endif
 
 	retval = setup_irq(irq, action);
 	if (retval)
diff -urNp linux-2.6.22-orig/lib/Kconfig.debug linux-2.6.22-pendirq/lib/Kconfig.debug
--- linux-2.6.22-orig/lib/Kconfig.debug	2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22-pendirq/lib/Kconfig.debug	2007-07-19 17:05:52.000000000 +0900
@@ -77,15 +77,6 @@ config DEBUG_KERNEL
 	  Say Y here if you are developing drivers or trying to debug and
 	  identify kernel problems.
 
-config DEBUG_SHIRQ
-	bool "Debug shared IRQ handlers"
-	depends on DEBUG_KERNEL && GENERIC_HARDIRQS
-	help
-	  Enable this to generate a spurious interrupt as soon as a shared
-	  interrupt handler is registered, and just before one is deregistered.
-	  Drivers ought to be able to handle interrupts coming in at those
-	  points; some don't and need to be caught.
-
 config DETECT_SOFTLOCKUP
 	bool "Detect Soft Lockups"
 	depends on DEBUG_KERNEL && !S390




From fernando at oss.ntt.co.jp  Thu Jul 19 22:20:43 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Fri, 20 Jul 2007 11:20:43 +0900
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>

With the advent of kdump it is possible that device drivers receive
interrupts generated in the context of a previous kernel. Ideally
quiescing the underlying devices should suffice but not all drivers do
this, either because it is not possible or because they did not
contemplate this case. Thus drivers ought to be able to handle
interrupts coming in as soon as the interrupt handler is registered.

Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
---

diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22-pendirq/kernel/irq/manage.c
--- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-19 18:18:53.000000000 +0900
+++ linux-2.6.22-pendirq/kernel/irq/manage.c	2007-07-19 19:43:41.000000000 +0900
@@ -533,21 +533,32 @@ int request_irq(unsigned int irq, irq_ha
 
 	select_smp_affinity(irq);
 
-	if (irqflags & IRQF_SHARED) {
-		/*
-		 * It's a shared IRQ -- the driver ought to be prepared for it
-		 * to happen immediately, so let's make sure....
-		 * We do this before actually registering it, to make sure that
-		 * a 'real' IRQ doesn't run in parallel with our fake
-		 */
-		if (irqflags & IRQF_DISABLED) {
-			unsigned long flags;
+	/*
+	 * With the advent of kdump it possible that device drivers receive
+	 * interrupts generated in the context of a previous kernel. Ideally
+	 * quiescing the underlying devices should suffice but not all drivers
+	 * do this, either because it is not possible or because they did not
+	 * contemplate this case. Thus drivers ought to be able to handle
+	 * interrupts coming in as soon as the interrupt handler is registered.
+	 *
+	 * Besides, if it is a shared IRQ the driver ought to be prepared for
+	 * it to happen immediately too.
+	 *
+	 * We do this before actually registering it, to make sure that
+	 * a 'real' IRQ doesn't run in parallel with our fake.
+	 */
+	if (irqflags & IRQF_DISABLED) {
+		unsigned long flags;
 
-			local_irq_save(flags);
-			handler(irq, dev_id);
-			local_irq_restore(flags);
-		} else
-			handler(irq, dev_id);
+		local_irq_save(flags);
+		retval = handler(irq, dev_id);
+		local_irq_restore(flags);
+	} else
+		retval = handler(irq, dev_id);
+	if (retval == IRQ_HANDLED) {
+		printk(KERN_WARNING
+		       "%s (IRQ %d) handled a spurious interrupt\n",
+		       devname, irq);
 	}
 
 	retval = setup_irq(irq, action);




From jesper.juhl at gmail.com  Sat Jul 21 11:03:29 2007
From: jesper.juhl at gmail.com (Jesper Juhl)
Date: Sat, 21 Jul 2007 17:03:29 +0200
Subject: [PATCH][24/37] Clean up duplicate includes in kernel/
Message-ID: <200707211703.30346.jesper.juhl@gmail.com>

Hi,

This patch cleans up duplicate includes in
	kernel/


Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
---

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 145cbb7..5f7dba2 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -45,7 +45,6 @@
 #include <linux/init.h>
 #include <asm/types.h>
 #include <asm/atomic.h>
-#include <asm/types.h>
 #include <linux/fs.h>
 #include <linux/namei.h>
 #include <linux/mm.h>
diff --git a/kernel/exit.c b/kernel/exit.c
index 464c2b1..9eef513 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -45,7 +45,6 @@
 #include <linux/resource.h>
 #include <linux/blkdev.h>
 #include <linux/task_io_accounting_ops.h>
-#include <linux/freezer.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 25db14b..d8de12e 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -17,7 +17,6 @@
 #include <linux/highmem.h>
 #include <linux/syscalls.h>
 #include <linux/reboot.h>
-#include <linux/syscalls.h>
 #include <linux/ioport.h>
 #include <linux/hardirq.h>
 #include <linux/elf.h>
diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
index 2c2dd84..5d9e07e 100644
--- a/kernel/rcupdate.c
+++ b/kernel/rcupdate.c
@@ -45,7 +45,6 @@
 #include <linux/moduleparam.h>
 #include <linux/percpu.h>
 #include <linux/notifier.h>
-#include <linux/rcupdate.h>
 #include <linux/cpu.h>
 #include <linux/mutex.h>
 
diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
index ddff332..dd413bf 100644
--- a/kernel/rcutorture.c
+++ b/kernel/rcutorture.c
@@ -35,7 +35,6 @@
 #include <linux/sched.h>
 #include <asm/atomic.h>
 #include <linux/bitops.h>
-#include <linux/module.h>
 #include <linux/completion.h>
 #include <linux/moduleparam.h>
 #include <linux/percpu.h>
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 2222998..e0b2456 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -27,7 +27,6 @@
 #include <linux/capability.h>
 #include <linux/ctype.h>
 #include <linux/utsname.h>
-#include <linux/capability.h>
 #include <linux/smp_lock.h>
 #include <linux/fs.h>
 #include <linux/init.h>
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index 059431e..7d4d7f9 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -20,7 +20,6 @@
 #include <linux/taskstats_kern.h>
 #include <linux/tsacct_kern.h>
 #include <linux/delayacct.h>
-#include <linux/tsacct_kern.h>
 #include <linux/cpumask.h>
 #include <linux/percpu.h>
 #include <net/genetlink.h>
diff --git a/kernel/time.c b/kernel/time.c
index 5b81da0..6304942 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -34,7 +34,6 @@
 #include <linux/syscalls.h>
 #include <linux/security.h>
 #include <linux/fs.h>
-#include <linux/module.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>


From paulmck at linux.vnet.ibm.com  Sat Jul 21 18:45:27 2007
From: paulmck at linux.vnet.ibm.com (Paul E. McKenney)
Date: Sat, 21 Jul 2007 15:45:27 -0700
Subject: [PATCH][24/37] Clean up duplicate includes in kernel/
In-Reply-To: <200707211703.30346.jesper.juhl@gmail.com>
References: <200707211703.30346.jesper.juhl@gmail.com>
Message-ID: <20070721224527.GB11746@linux.vnet.ibm.com>

On Sat, Jul 21, 2007 at 05:03:29PM +0200, Jesper Juhl wrote:
> Hi,
> 
> This patch cleans up duplicate includes in
> 	kernel/

Changes to kernel/rcupdate.c and kernel/rcutorture.c:

Acked-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com>

> Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
> ---
> 
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 145cbb7..5f7dba2 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -45,7 +45,6 @@
>  #include <linux/init.h>
>  #include <asm/types.h>
>  #include <asm/atomic.h>
> -#include <asm/types.h>
>  #include <linux/fs.h>
>  #include <linux/namei.h>
>  #include <linux/mm.h>
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 464c2b1..9eef513 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -45,7 +45,6 @@
>  #include <linux/resource.h>
>  #include <linux/blkdev.h>
>  #include <linux/task_io_accounting_ops.h>
> -#include <linux/freezer.h>
> 
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 25db14b..d8de12e 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -17,7 +17,6 @@
>  #include <linux/highmem.h>
>  #include <linux/syscalls.h>
>  #include <linux/reboot.h>
> -#include <linux/syscalls.h>
>  #include <linux/ioport.h>
>  #include <linux/hardirq.h>
>  #include <linux/elf.h>
> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> index 2c2dd84..5d9e07e 100644
> --- a/kernel/rcupdate.c
> +++ b/kernel/rcupdate.c
> @@ -45,7 +45,6 @@
>  #include <linux/moduleparam.h>
>  #include <linux/percpu.h>
>  #include <linux/notifier.h>
> -#include <linux/rcupdate.h>
>  #include <linux/cpu.h>
>  #include <linux/mutex.h>
> 
> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> index ddff332..dd413bf 100644
> --- a/kernel/rcutorture.c
> +++ b/kernel/rcutorture.c
> @@ -35,7 +35,6 @@
>  #include <linux/sched.h>
>  #include <asm/atomic.h>
>  #include <linux/bitops.h>
> -#include <linux/module.h>
>  #include <linux/completion.h>
>  #include <linux/moduleparam.h>
>  #include <linux/percpu.h>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 2222998..e0b2456 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -27,7 +27,6 @@
>  #include <linux/capability.h>
>  #include <linux/ctype.h>
>  #include <linux/utsname.h>
> -#include <linux/capability.h>
>  #include <linux/smp_lock.h>
>  #include <linux/fs.h>
>  #include <linux/init.h>
> diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> index 059431e..7d4d7f9 100644
> --- a/kernel/taskstats.c
> +++ b/kernel/taskstats.c
> @@ -20,7 +20,6 @@
>  #include <linux/taskstats_kern.h>
>  #include <linux/tsacct_kern.h>
>  #include <linux/delayacct.h>
> -#include <linux/tsacct_kern.h>
>  #include <linux/cpumask.h>
>  #include <linux/percpu.h>
>  #include <net/genetlink.h>
> diff --git a/kernel/time.c b/kernel/time.c
> index 5b81da0..6304942 100644
> --- a/kernel/time.c
> +++ b/kernel/time.c
> @@ -34,7 +34,6 @@
>  #include <linux/syscalls.h>
>  #include <linux/security.h>
>  #include <linux/fs.h>
> -#include <linux/module.h>
> 
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>


From satyam.sharma at gmail.com  Sat Jul 21 21:44:56 2007
From: satyam.sharma at gmail.com (Satyam Sharma)
Date: Sun, 22 Jul 2007 07:14:56 +0530
Subject: [PATCH][24/37] Clean up duplicate includes in kernel/
In-Reply-To: <200707211703.30346.jesper.juhl@gmail.com>
References: <200707211703.30346.jesper.juhl@gmail.com>
Message-ID: <a781481a0707211844s40e203c4t51250ff421d8781d@mail.gmail.com>

On 7/21/07, Jesper Juhl <jesper.juhl at gmail.com> wrote:
> Hi,
>
> This patch cleans up duplicate includes in
>         kernel/
>
>
> Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>

Reviewed-by: Satyam Sharma <ssatyam at cse.iitk.ac.in>

[ Jesper, I hope you re-built with all these changes? Some
of these duplicate #include's could have been hiding deeper
header-include-ordering problems, and we'd want to know
about that too. Otherwise looks fairly obvious, thanks. ]

> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 145cbb7..5f7dba2 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -45,7 +45,6 @@
>  #include <linux/init.h>
>  #include <asm/types.h>
>  #include <asm/atomic.h>
> -#include <asm/types.h>
>  #include <linux/fs.h>
>  #include <linux/namei.h>
>  #include <linux/mm.h>

Ack

> diff --git a/kernel/exit.c b/kernel/exit.c
> index 464c2b1..9eef513 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -45,7 +45,6 @@
>  #include <linux/resource.h>
>  #include <linux/blkdev.h>
>  #include <linux/task_io_accounting_ops.h>
> -#include <linux/freezer.h>
>
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>

Ack

> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 25db14b..d8de12e 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -17,7 +17,6 @@
>  #include <linux/highmem.h>
>  #include <linux/syscalls.h>
>  #include <linux/reboot.h>
> -#include <linux/syscalls.h>
>  #include <linux/ioport.h>
>  #include <linux/hardirq.h>
>  #include <linux/elf.h>

Ack

> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> index 2c2dd84..5d9e07e 100644
> --- a/kernel/rcupdate.c
> +++ b/kernel/rcupdate.c
> @@ -45,7 +45,6 @@
>  #include <linux/moduleparam.h>
>  #include <linux/percpu.h>
>  #include <linux/notifier.h>
> -#include <linux/rcupdate.h>
>  #include <linux/cpu.h>
>  #include <linux/mutex.h>

Ack

> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> index ddff332..dd413bf 100644
> --- a/kernel/rcutorture.c
> +++ b/kernel/rcutorture.c
> @@ -35,7 +35,6 @@
>  #include <linux/sched.h>
>  #include <asm/atomic.h>
>  #include <linux/bitops.h>
> -#include <linux/module.h>
>  #include <linux/completion.h>
>  #include <linux/moduleparam.h>
>  #include <linux/percpu.h>

Ack

> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 2222998..e0b2456 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -27,7 +27,6 @@
>  #include <linux/capability.h>
>  #include <linux/ctype.h>
>  #include <linux/utsname.h>
> -#include <linux/capability.h>
>  #include <linux/smp_lock.h>
>  #include <linux/fs.h>
>  #include <linux/init.h>

Ack

> diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> index 059431e..7d4d7f9 100644
> --- a/kernel/taskstats.c
> +++ b/kernel/taskstats.c
> @@ -20,7 +20,6 @@
>  #include <linux/taskstats_kern.h>
>  #include <linux/tsacct_kern.h>
>  #include <linux/delayacct.h>
> -#include <linux/tsacct_kern.h>
>  #include <linux/cpumask.h>
>  #include <linux/percpu.h>
>  #include <net/genetlink.h>

Ack

> diff --git a/kernel/time.c b/kernel/time.c
> index 5b81da0..6304942 100644
> --- a/kernel/time.c
> +++ b/kernel/time.c
> @@ -34,7 +34,6 @@
>  #include <linux/syscalls.h>
>  #include <linux/security.h>
>  #include <linux/fs.h>
> -#include <linux/module.h>
>
>  #include <asm/uaccess.h>
>  #include <asm/unistd.h>

Ack


From jesper.juhl at gmail.com  Sun Jul 22 01:07:32 2007
From: jesper.juhl at gmail.com (Jesper Juhl)
Date: Sun, 22 Jul 2007 07:07:32 +0200
Subject: [PATCH][24/37] Clean up duplicate includes in kernel/
In-Reply-To: <a781481a0707211844s40e203c4t51250ff421d8781d@mail.gmail.com>
References: <200707211703.30346.jesper.juhl@gmail.com>
	<a781481a0707211844s40e203c4t51250ff421d8781d@mail.gmail.com>
Message-ID: <9a8748490707212207h63abdb94o3d27a24d67a0ca12@mail.gmail.com>

On 22/07/07, Satyam Sharma <satyam.sharma at gmail.com> wrote:
> On 7/21/07, Jesper Juhl <jesper.juhl at gmail.com> wrote:
> > Hi,
> >
> > This patch cleans up duplicate includes in
> >         kernel/
> >
> >
> > Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
>
> Reviewed-by: Satyam Sharma <ssatyam at cse.iitk.ac.in>
>
> [ Jesper, I hope you re-built with all these changes? Some
> of these duplicate #include's could have been hiding deeper
> header-include-ordering problems, and we'd want to know
> about that too. Otherwise looks fairly obvious, thanks. ]
>
I build an allmodconfig kernel, an allnoconfig one as well as one with
my regular config for my home machine.

-- 
Jesper Juhl <jesper.juhl at gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html


From vgoyal at in.ibm.com  Mon Jul 23 01:01:47 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 23 Jul 2007 10:31:47 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070719163915.GN9623@redhat.com>
References: <20070716123633.GA10920@in.ibm.com>
	<20070718230740oomichi@mail.jp.nec.com>
	<20070719163915.GN9623@redhat.com>
Message-ID: <20070723050147.GA5691@in.ibm.com>

On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
[..]
> 
> I am not a big fan of this approach as it forces distros to require
> kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
> kernel (and not interested in kexec) would have to not only download the
> kernel.src.rpm but kexec-tools just to build a kernel that probably
> doesn't have kexec enabled.
> 
> I had to deal with a similar experience when providing a build dependency
> on the unifdef package when create the kernel-headers rpm for RHEL-5.  A
> lot of people were confused and upset by this dependency.  Luckily
> upstream resolved this by just putting similar code in the kernel/scripts
> directory and thus removing the dependency (well not for RHEL-5).  I would
> rather not have to deal with this again unless I know there is a more
> permanent solution that would remove this dependency.
> 

That's a good point Don. kernel rpm being dependent on kexec-tools rpm is
not a good idea.

> After talking to Dave Anderson about this more, I start to understand why
> Ken'ichi prefers to implement the new features in userspace instead of the
> kernel (it makes things automatically work with older kernels), but I
> still am not a big fan of it.  I was hoping for a complete in kernel
> solution (that way you never need the vmlinux file).  Perhaps makedumpfile
> can support both vmlinux files (if provided) or interface with the kernel
> (if the vmlinux is not provided?).
> 

I am also in favour of a complete kernel based solution. Export required
info from kernel and let kexec-tools parse that info, pass it to second
kernel and it will be appended to vmcore.

This will put some restrictions on that we can't keep on changing the
format of the info very frequently and some new features might not work
with older kernels. But I guess, kexec-tools can provide an override option
where dump filtering info can be passed on kexec-tools command line (as
suggested by ken'chi). If user passes this info on command line then
kexec-tools will not read the info exported from kernel. This way new
features can be made to work on older kernels. 

Thanks
Vivek


From oomichi at mxs.nes.nec.co.jp  Mon Jul 23 07:47:23 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Mon, 23 Jul 2007 20:47:23 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070723050147.GA5691@in.ibm.com>
References: <20070723050147.GA5691@in.ibm.com>
Message-ID: <20070723204723oomichi@mail.jp.nec.com>


Hi,

2007/07/23 10:31:47 +0530, Vivek Goyal <vgoyal at in.ibm.com> wrote:
>On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
>[..]
>> 
>> I am not a big fan of this approach as it forces distros to require
>> kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
>> kernel (and not interested in kexec) would have to not only download the
>> kernel.src.rpm but kexec-tools just to build a kernel that probably
>> doesn't have kexec enabled.
>> 
>> I had to deal with a similar experience when providing a build dependency
>> on the unifdef package when create the kernel-headers rpm for RHEL-5.  A
>> lot of people were confused and upset by this dependency.  Luckily
>> upstream resolved this by just putting similar code in the kernel/scripts
>> directory and thus removing the dependency (well not for RHEL-5).  I would
>> rather not have to deal with this again unless I know there is a more
>> permanent solution that would remove this dependency.
>> 
>
>That's a good point Don. kernel rpm being dependent on kexec-tools rpm is
>not a good idea.

That's right. The kernel package should not be dependent on kexec-tools
package (including makedumpfile). I understand Dan Aloni's proposal
(including the dump filtering information in kernel) makes many
advantages. Ok, I agree with his proposal.

BTW, we should test makedumpfile by each linux(-rc1 ?) releases.
Now, I test the makedumpfile functions by comparing the crash utility's
output of /proc/vmcore and the one of the filtered dumpfile.
Often, the crash utility cannot read /proc/vmcore of the latest kernel.
Does anybody know the crash's option that the crash can run loosely for
the early test ?


>> After talking to Dave Anderson about this more, I start to understand why
>> Ken'ichi prefers to implement the new features in userspace instead of the
>> kernel (it makes things automatically work with older kernels), but I
>> still am not a big fan of it.  I was hoping for a complete in kernel
>> solution (that way you never need the vmlinux file).  Perhaps makedumpfile
>> can support both vmlinux files (if provided) or interface with the kernel
>> (if the vmlinux is not provided?).
>> 
>
>I am also in favour of a complete kernel based solution. Export required
>info from kernel and let kexec-tools parse that info, pass it to second
>kernel and it will be appended to vmcore.
>
>This will put some restrictions on that we can't keep on changing the
>format of the info very frequently and some new features might not work
>with older kernels. But I guess, kexec-tools can provide an override option
>where dump filtering info can be passed on kexec-tools command line (as
>suggested by ken'chi). If user passes this info on command line then
>kexec-tools will not read the info exported from kernel. This way new
>features can be made to work on older kernels. 

That sounds good.


Dan Aloni, I'd like to cooperate with you for implementing this feature.
If you have some patches other than 2007/07/10 patches, could you send
me them ?  I will update them.


Thanks
Ken'ichi Ohmichi


From da-x at monatomic.org  Mon Jul 23 09:02:39 2007
From: da-x at monatomic.org (Dan Aloni)
Date: Mon, 23 Jul 2007 16:02:39 +0300
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070723204723oomichi@mail.jp.nec.com>
References: <20070723050147.GA5691@in.ibm.com>
	<20070723204723oomichi@mail.jp.nec.com>
Message-ID: <20070723130239.GA311@localdomain>

On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> 2007/07/23 10:31:47 +0530, Vivek Goyal <vgoyal at in.ibm.com> wrote:
[..]
> >
> >I am also in favour of a complete kernel based solution. Export required
> >info from kernel and let kexec-tools parse that info, pass it to second
> >kernel and it will be appended to vmcore.
> >
> >This will put some restrictions on that we can't keep on changing the
> >format of the info very frequently and some new features might not work
> >with older kernels. But I guess, kexec-tools can provide an override option
> >where dump filtering info can be passed on kexec-tools command line (as
> >suggested by ken'chi). If user passes this info on command line then
> >kexec-tools will not read the info exported from kernel. This way new
> >features can be made to work on older kernels. 
> 
> That sounds good.

Note that currently kexec doesn't actually pass the ELF notes themselves
to the kernel, but only their physical addresses as extracted from /sys. 
If we want to be able to pass the notes themselves from userspace, a 
little more trickery will be needed here.

> Dan Aloni, I'd like to cooperate with you for implementing this feature.
> If you have some patches other than 2007/07/10 patches, could you send
> me them ?  I will update them.

Sure, though I haven't made new patches (was busy with other things). 
Feel free to post new versions of these patches, I'll take a look and 
cooperate with you on this.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il


From vgoyal at in.ibm.com  Mon Jul 23 11:58:03 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 23 Jul 2007 21:28:03 +0530
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070723130239.GA311@localdomain>
References: <20070723050147.GA5691@in.ibm.com>
	<20070723204723oomichi@mail.jp.nec.com>
	<20070723130239.GA311@localdomain>
Message-ID: <20070723155803.GA30193@in.ibm.com>

On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote:
> On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
> > 
> > Hi,
> > 
> > 2007/07/23 10:31:47 +0530, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> [..]
> > >
> > >I am also in favour of a complete kernel based solution. Export required
> > >info from kernel and let kexec-tools parse that info, pass it to second
> > >kernel and it will be appended to vmcore.
> > >
> > >This will put some restrictions on that we can't keep on changing the
> > >format of the info very frequently and some new features might not work
> > >with older kernels. But I guess, kexec-tools can provide an override option
> > >where dump filtering info can be passed on kexec-tools command line (as
> > >suggested by ken'chi). If user passes this info on command line then
> > >kexec-tools will not read the info exported from kernel. This way new
> > >features can be made to work on older kernels. 
> > 
> > That sounds good.
> 
> Note that currently kexec doesn't actually pass the ELF notes themselves
> to the kernel, but only their physical addresses as extracted from /sys. 
> If we want to be able to pass the notes themselves from userspace, a 
> little more trickery will be needed here.
> 

That should be easy. Like so many other segments kexec prepares, one
more segment need to be created and required elf note data needs to be
put in this segment. 

Right now we create a PT_NOTE type ELF header for every cpu. Now we need
to create few more notes to pass on the OS release, config variables and
debug data to second kernel.

Should we create a separate note for passing on kernel config info something
like "linuxconfig" and every note will contain CONFIG_VARIABLE=VALUE string?

Probably something similar can be done for appropriate debugging data 
instead of putting all the info in one ELF note. Breaking the required
info into multiple generic notes will help it to be used in other things
also down the line. Just a thought....

Thanks
Vivek


From anderson at redhat.com  Mon Jul 23 17:08:22 2007
From: anderson at redhat.com (Dave Anderson)
Date: Mon, 23 Jul 2007 17:08:22 -0400
Subject: Determine version of kernel that produced vmcore 
Message-ID: <46A518C6.5070108@redhat.com>



 > From: "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp>
...
 >
 > BTW, we should test makedumpfile by each linux(-rc1 ?) releases.
 > Now, I test the makedumpfile functions by comparing the crash utility's
 > output of /proc/vmcore and the one of the filtered dumpfile.
 > Often, the crash utility cannot read /proc/vmcore of the latest kernel.
 > Does anybody know the crash's option that the crash can run loosely for
 > the early test ?

There is no "loosely-run" option for the crash utility.

When you state "cannot read /proc/vmcore", I'm presuming that
you mean that something fails during initialization due to
the "shifting sands" of the upstream kernel (and which should
be reported to the crash-utility list so that it can be
addressed...)

There are a couple debug-only options that prevent crash from
accessing certain subsystems during initialization, such as
"--no_kmem_cache" to avoid traversing the kmalloc/slab subsystem,
and "--no_modules" to avoid traversing the vmalloc'd module list.
Those two may help if you have an "incomplete" dumpfile that is
missing pages that *should* be there.  There's also a "-f" to
force the use of split vmlinux/vmlinux.debug pair whose CRC's
do not match.  But if you're using a simple -g build vmlinux
files, that option wouldn't apply.

Dave

 >
 > Thanks
 > Ken'ichi Ohmichi







From anderson at redhat.com  Mon Jul 23 15:19:20 2007
From: anderson at redhat.com (Dave Anderson)
Date: Mon, 23 Jul 2007 15:19:20 -0400
Subject: kexec Digest, Vol 4, Issue 28
In-Reply-To: <mailman.13.1185206419.4831.kexec@lists.infradead.org>
References: <mailman.13.1185206419.4831.kexec@lists.infradead.org>
Message-ID: <46A4FF38.5000504@redhat.com>


> From: "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp>
> Subject: Re: Determine version of kernel that produced vmcore
...
> 
> BTW, we should test makedumpfile by each linux(-rc1 ?) releases.
> Now, I test the makedumpfile functions by comparing the crash utility's
> output of /proc/vmcore and the one of the filtered dumpfile.
> Often, the crash utility cannot read /proc/vmcore of the latest kernel.
> Does anybody know the crash's option that the crash can run loosely for
> the early test ?

There is no "loosely-run" option for the crash utility.

When you state "cannot read /proc/vmcore", I'm presuming that
you mean that something fails during initialization due to
the "shifting sands" of the upstream kernel (and which should
be reported to the crash-utility list so that it can be
addressed...)

There are a couple debug-only options that prevent crash from
accessing certain subsystems during initialization, such as
"--no_kmem_cache" to avoid traversing the kmalloc/slab subsystem,
and "--no_modules" to avoid traversing the vmalloc'd module list.
Those two may help if you have an "incomplete" dumpfile that is
missing pages that *should* be there.  There's also a "-f" to
force the use of split vmlinux/vmlinux.debug pair whose CRC's
do not match.  But if you're using a simple -g build vmlinux
files, that option wouldn't apply.

Dave


> 
> Thanks
> Ken'ichi Ohmichi





From oomichi at mxs.nes.nec.co.jp  Tue Jul 24 02:40:54 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Tue, 24 Jul 2007 15:40:54 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070723130239.GA311@localdomain>
References: <20070723130239.GA311@localdomain>
Message-ID: <20070724154054oomichi@mail.jp.nec.com>


Hi Dan,

2007/07/23 16:02:39 +0300, Dan Aloni <da-x at monatomic.org> wrote:
>> Dan Aloni, I'd like to cooperate with you for implementing this feature.
>> If you have some patches other than 2007/07/10 patches, could you send
>> me them ?  I will update them.
>
>Sure, though I haven't made new patches (was busy with other things). 
>Feel free to post new versions of these patches, I'll take a look and 
>cooperate with you on this.

OK. Now, I am testing a new makedumpfile including some corrections
and some features to release it in July. I'll start making new patches
after the release.


Thanks
Ken'ichi Ohmichi


From oomichi at mxs.nes.nec.co.jp  Tue Jul 24 02:41:50 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Tue, 24 Jul 2007 15:41:50 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <46A518C6.5070108@redhat.com>
References: <46A518C6.5070108@redhat.com>
Message-ID: <20070724154150oomichi@mail.jp.nec.com>


Hi Dave,

2007/07/23 17:08:22 -0400, Dave Anderson <anderson at redhat.com> wrote:
> > From: "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp>
>...
> >
> > BTW, we should test makedumpfile by each linux(-rc1 ?) releases.
> > Now, I test the makedumpfile functions by comparing the crash utility's
> > output of /proc/vmcore and the one of the filtered dumpfile.
> > Often, the crash utility cannot read /proc/vmcore of the latest kernel.
> > Does anybody know the crash's option that the crash can run loosely for
> > the early test ?
>
>There is no "loosely-run" option for the crash utility.
>
>When you state "cannot read /proc/vmcore", I'm presuming that
>you mean that something fails during initialization due to
>the "shifting sands" of the upstream kernel (and which should
>be reported to the crash-utility list so that it can be
>addressed...)

As you said, I saw some problems that the crash utility failed
during the initialization. I will report them to the crash-utility
list if I find them.


>There are a couple debug-only options that prevent crash from
>accessing certain subsystems during initialization, such as
>"--no_kmem_cache" to avoid traversing the kmalloc/slab subsystem,
>and "--no_modules" to avoid traversing the vmalloc'd module list.
>Those two may help if you have an "incomplete" dumpfile that is
>missing pages that *should* be there.  There's also a "-f" to
>force the use of split vmlinux/vmlinux.debug pair whose CRC's
>do not match.  But if you're using a simple -g build vmlinux
>files, that option wouldn't apply.

Thank you for the information.
I will use the above options until we update the crash utility.


Thanks
Ken'ichi Ohmichi


From oomichi at mxs.nes.nec.co.jp  Tue Jul 24 02:49:28 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Tue, 24 Jul 2007 15:49:28 +0900
Subject: Determine version of kernel that produced vmcore
In-Reply-To: <20070718231050.GB25660@suse.de>
References: <20070718231050.GB25660@suse.de>
Message-ID: <20070724154928oomichi@mail.jp.nec.com>


Hi Bernhard,

2007/07/19 01:10:50 +0200, Bernhard Walle <bwalle at suse.de> wrote:
>[1] didn't we agree to vmcoreinfo?

I agree to vmcoreinfo.
I'll rename makedumpfile's config file to "vmcoreinfo".


Thanks
Ken'ichi Ohmichi


From ying.huang at intel.com  Tue Jul 24 10:00:04 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Tue, 24 Jul 2007 22:00:04 +0800
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <200707151249.26148.rjw@sisk.pl>
Message-ID: <9D7649D18729DE4BB2BD7B494F7FEDC236CF66@pdsmsx415.ccr.corp.intel.com>

>From: Rafael J. Wysocki [mailto:rjw at sisk.pl]
>This is not the point.  There are memory regions that you should not
_restore_,
>because that will cause harm.
>
>> On x86_64, there is another usage of nosave during processing E820
>> memory map. But I don't know why the memory region other than
E820_RAM
>> are marked as nosave. I think only the memory region of type E820_RAM
>> will be thought of normal memory, others will be thought as reserved.
Is
>> it sufficient just to check whether the page is reserved?
>
>No, it's not.

The "/proc/iomem" records information of all memory regions including
"normal RAM" and all kinds of reserved regions, which is backed by
iomem_resource. On x86_64, it is initialized in the exact same way as
nosave region initialization.

I think maybe we can replace the "nosave region" concepts with
"iomem_resource" (maybe need some enhancement).

Best Regards,
Huang Ying


From rjw at sisk.pl  Tue Jul 24 11:27:34 2007
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Tue, 24 Jul 2007 17:27:34 +0200
Subject: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
In-Reply-To: <9D7649D18729DE4BB2BD7B494F7FEDC236CF66@pdsmsx415.ccr.corp.intel.com>
References: <9D7649D18729DE4BB2BD7B494F7FEDC236CF66@pdsmsx415.ccr.corp.intel.com>
Message-ID: <200707241727.35589.rjw@sisk.pl>

On Tuesday, 24 July 2007 16:00, Huang, Ying wrote:
> >From: Rafael J. Wysocki [mailto:rjw at sisk.pl]
> >This is not the point.  There are memory regions that you should not
> _restore_,
> >because that will cause harm.
> >
> >> On x86_64, there is another usage of nosave during processing E820
> >> memory map. But I don't know why the memory region other than
> E820_RAM
> >> are marked as nosave. I think only the memory region of type E820_RAM
> >> will be thought of normal memory, others will be thought as reserved.
> Is
> >> it sufficient just to check whether the page is reserved?
> >
> >No, it's not.
> 
> The "/proc/iomem" records information of all memory regions including
> "normal RAM" and all kinds of reserved regions, which is backed by
> iomem_resource. On x86_64, it is initialized in the exact same way as
> nosave region initialization.
> 
> I think maybe we can replace the "nosave region" concepts with
> "iomem_resource" (maybe need some enhancement).

Yes, I think that might be done.

Geetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth


From bwalle at suse.de  Thu Jul 26 10:07:02 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 26 Jul 2007 16:07:02 +0200
Subject: [patch] add kdump_after_notifier
In-Reply-To: <469F55D0.4050203@ah.jp.nec.com>
References: <469F55D0.4050203@ah.jp.nec.com>
Message-ID: <20070726140702.GA8949@suse.de>

* Takenori Nagano <t-nagano at ah.jp.nec.com> [2007-07-19 14:15]:
> 
> In latest kernel, we can't use panic_notifier_list if kdump is enabled.
> panic_notifier_list is very useful function for debug, failover, etc...
> 
> So this patch adds a control file /proc/sys/kernel/dump_after_notifier
> and resolves a problem users can not use both kdump and panic_notifier_list
> at the same time.
> 
> kdump_after_notifier = 0
>  -> panic()
>     -> crash_kexec(NULL)
> 
> kdump_after_notifier = 1
>  -> panic()
>     -> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
>     -> crash_kexec(NULL)

What's problematic about this patch? I also would like to see that
feature.


Thanks,
   Bernhard


From vgoyal at in.ibm.com  Thu Jul 26 11:32:40 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Thu, 26 Jul 2007 21:02:40 +0530
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726140702.GA8949@suse.de>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
Message-ID: <20070726153240.GA15969@in.ibm.com>

On Thu, Jul 26, 2007 at 04:07:02PM +0200, Bernhard Walle wrote:
> * Takenori Nagano <t-nagano at ah.jp.nec.com> [2007-07-19 14:15]:
> > 
> > In latest kernel, we can't use panic_notifier_list if kdump is enabled.
> > panic_notifier_list is very useful function for debug, failover, etc...
> > 
> > So this patch adds a control file /proc/sys/kernel/dump_after_notifier
> > and resolves a problem users can not use both kdump and panic_notifier_list
> > at the same time.
> > 
> > kdump_after_notifier = 0
> >  -> panic()
> >     -> crash_kexec(NULL)
> > 
> > kdump_after_notifier = 1
> >  -> panic()
> >     -> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
> >     -> crash_kexec(NULL)
> 
> What's problematic about this patch? I also would like to see that
> feature.

I would like to see the code which will get executed after panic and 
before crash_kexec(). This potentially makes crash dump feature unreliable
in the sense one can now register on panic_notifier_list and try to
do whole lot of things and might get stuck there. After the system
has crashed, one is not supposed to do a whole lot.

Thanks
Vivek


From bwalle at suse.de  Thu Jul 26 11:34:40 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 26 Jul 2007 17:34:40 +0200
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726153240.GA15969@in.ibm.com>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
Message-ID: <20070726153440.GA19095@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:32]:
> On Thu, Jul 26, 2007 at 04:07:02PM +0200, Bernhard Walle wrote:
> > * Takenori Nagano <t-nagano at ah.jp.nec.com> [2007-07-19 14:15]:
> > > 
> > > In latest kernel, we can't use panic_notifier_list if kdump is enabled.
> > > panic_notifier_list is very useful function for debug, failover, etc...
> > > 
> > > So this patch adds a control file /proc/sys/kernel/dump_after_notifier
> > > and resolves a problem users can not use both kdump and panic_notifier_list
> > > at the same time.
> > > 
> > > kdump_after_notifier = 0
> > >  -> panic()
> > >     -> crash_kexec(NULL)
> > > 
> > > kdump_after_notifier = 1
> > >  -> panic()
> > >     -> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
> > >     -> crash_kexec(NULL)
> > 
> > What's problematic about this patch? I also would like to see that
> > feature.
> 
> I would like to see the code which will get executed after panic and 
> before crash_kexec(). This potentially makes crash dump feature unreliable
> in the sense one can now register on panic_notifier_list and try to
> do whole lot of things and might get stuck there. After the system
> has crashed, one is not supposed to do a whole lot.

Of course, but that's why the patch doesn't change this by default but
gives the user the choice.


Thanks,
   Bernhard


From vgoyal at in.ibm.com  Thu Jul 26 11:44:15 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Thu, 26 Jul 2007 21:14:15 +0530
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726153440.GA19095@suse.de>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
Message-ID: <20070726154415.GB15969@in.ibm.com>

On Thu, Jul 26, 2007 at 05:34:40PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:32]:
> > On Thu, Jul 26, 2007 at 04:07:02PM +0200, Bernhard Walle wrote:
> > > * Takenori Nagano <t-nagano at ah.jp.nec.com> [2007-07-19 14:15]:
> > > > 
> > > > In latest kernel, we can't use panic_notifier_list if kdump is enabled.
> > > > panic_notifier_list is very useful function for debug, failover, etc...
> > > > 
> > > > So this patch adds a control file /proc/sys/kernel/dump_after_notifier
> > > > and resolves a problem users can not use both kdump and panic_notifier_list
> > > > at the same time.
> > > > 
> > > > kdump_after_notifier = 0
> > > >  -> panic()
> > > >     -> crash_kexec(NULL)
> > > > 
> > > > kdump_after_notifier = 1
> > > >  -> panic()
> > > >     -> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
> > > >     -> crash_kexec(NULL)
> > > 
> > > What's problematic about this patch? I also would like to see that
> > > feature.
> > 
> > I would like to see the code which will get executed after panic and 
> > before crash_kexec(). This potentially makes crash dump feature unreliable
> > in the sense one can now register on panic_notifier_list and try to
> > do whole lot of things and might get stuck there. After the system
> > has crashed, one is not supposed to do a whole lot.
> 
> Of course, but that's why the patch doesn't change this by default but
> gives the user the choice.
> 

I am skeptical that how many users will really know that whether to set
this option as 1 or 0. Telling them setting it zero is  more reliable as
compared to 1 is kind of vague. What value will distro set it to by default?

Can we be more specific in terms of functionality and code that exactly
what we are trying to do after panic?

Thanks
Vivek

> 
> Thanks,
>    Bernhard


From bwalle at suse.de  Thu Jul 26 11:47:18 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 26 Jul 2007 17:47:18 +0200
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726154415.GB15969@in.ibm.com>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
Message-ID: <20070726154718.GA25561@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:44]:
> > 
> > Of course, but that's why the patch doesn't change this by default but
> > gives the user the choice.
> > 
> 
> What value will distro set it to by default?

0.

> Can we be more specific in terms of functionality and code that exactly
> what we are trying to do after panic?

Well, KDB, but now everybody answers with ?not mainline -- doesn't
count?.


Thanks,
   Bernhard


From vgoyal at in.ibm.com  Thu Jul 26 11:54:45 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Thu, 26 Jul 2007 21:24:45 +0530
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726154718.GA25561@suse.de>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>
Message-ID: <20070726155444.GC15969@in.ibm.com>

On Thu, Jul 26, 2007 at 05:47:18PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:44]:
> > > 
> > > Of course, but that's why the patch doesn't change this by default but
> > > gives the user the choice.
> > > 
> > 
> > What value will distro set it to by default?
> 
> 0.
> 
> > Can we be more specific in terms of functionality and code that exactly
> > what we are trying to do after panic?
> 
> Well, KDB, but now everybody answers with ?not mainline -- doesn't
> count?.
> 

That's true. Its not mainline. We had similar discussion in the past
also. I think we should allow only audited code to be run after panic().
Leaving it open to modules or unaudited code makes this solution
something like LKCD where whole lot of code used to run after the crash,
hence was unreliable.

If KDB goes mainline, then I think it is not a bad idea to call debugger
first (if it is enabled) and then one can trigger crash dump from inside
the debugger.

Thanks
Vivek


From bwalle at suse.de  Thu Jul 26 12:14:31 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 26 Jul 2007 18:14:31 +0200
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726155444.GC15969@in.ibm.com>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com>
Message-ID: <20070726161431.GA32008@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:54]:
> 
> That's true. Its not mainline. We had similar discussion in the past
> also. I think we should allow only audited code to be run after panic().
> Leaving it open to modules or unaudited code makes this solution
> something like LKCD where whole lot of code used to run after the crash,
> hence was unreliable.
> 
> If KDB goes mainline, then I think it is not a bad idea to call debugger
> first (if it is enabled) and then one can trigger crash dump from inside
> the debugger.

Well, after thinking again about this, I think the best solution would
to call kdump from KDB with a command as it was done by LKCD. The new
sysctl is too specific ...


Thanks,
   Bernhard


From bwalle at suse.de  Thu Jul 26 12:21:34 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Thu, 26 Jul 2007 18:21:34 +0200
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726161431.GA32008@suse.de>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com>
	<20070726161431.GA32008@suse.de>
Message-ID: <20070726162134.GA13880@suse.de>

* Bernhard Walle <bwalle at suse.de> [2007-07-26 18:14]:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:54]:
> > 
> > That's true. Its not mainline. We had similar discussion in the past
> > also. I think we should allow only audited code to be run after panic().
> > Leaving it open to modules or unaudited code makes this solution
> > something like LKCD where whole lot of code used to run after the crash,
> > hence was unreliable.
> > 
> > If KDB goes mainline, then I think it is not a bad idea to call debugger
> > first (if it is enabled) and then one can trigger crash dump from inside
> > the debugger.
> 
> Well, after thinking again about this, I think the best solution would
> to call kdump from KDB with a command as it was done by LKCD.

Ok, but that doesn't solve the problem (it would solve the opposite
problem).

My question is: Why cannot kdump use the notifier call chain? Wouldn't
this simplify things in general, apart from KDB. Not talking about the
priority of kdump now ...


Thanks,
   Bernhard



From t-nagano at ah.jp.nec.com  Thu Jul 26 19:28:48 2007
From: t-nagano at ah.jp.nec.com (Takenori Nagano)
Date: Fri, 27 Jul 2007 08:28:48 +0900
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070726155444.GC15969@in.ibm.com>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com>
Message-ID: <46A92E30.8070703@ah.jp.nec.com>

Hi Vivek,

Vivek Goyal wrote:
> On Thu, Jul 26, 2007 at 05:47:18PM +0200, Bernhard Walle wrote:
>> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:44]:
>>>> Of course, but that's why the patch doesn't change this by default but
>>>> gives the user the choice.
>>>>
>>> What value will distro set it to by default?
>> 0.
>>
>>> Can we be more specific in terms of functionality and code that exactly
>>> what we are trying to do after panic?
>> Well, KDB, but now everybody answers with ?not mainline -- doesn't
>> count?.
>>
> 
> That's true. Its not mainline. We had similar discussion in the past
> also. I think we should allow only audited code to be run after panic().
> Leaving it open to modules or unaudited code makes this solution
> something like LKCD where whole lot of code used to run after the crash,
> hence was unreliable.

It is *not* KDB specific problem. Please grep in mainline kernel. You can find
some function using panic_notifier_list. (IPMI, softdog, heartbeat, etc...)
My patch gives a chance to use kdump for panic_notifier user. It is good for
kdump too, because kdump user goes to increase. :-)

Bernhard's idea (kdump uses panic_notifier) is very good for me. But it isn't
good for kdump user, because they want to take a dump ASAP when panicked.

Vivek, please think about this problem again.

If there is a developer who has the opinion on this problem, please give us your
opinion.

Thanks.

> If KDB goes mainline, then I think it is not a bad idea to call debugger
> first (if it is enabled) and then one can trigger crash dump from inside
> the debugger.
> Thanks
> Vivek
> 
> 


From horms at verge.net.au  Fri Jul 27 01:12:37 2007
From: horms at verge.net.au (Horms)
Date: Fri, 27 Jul 2007 14:12:37 +0900
Subject: [PATCH] Determine ELF32/ELF64 automatically on i386
In-Reply-To: <20070710082316.GA17090@suse.de>
References: <20070702131541.GA6084@suse.de> <20070703161207.GA5070@suse.de>
	<20070710055259.GA5471@in.ibm.com> <20070710082316.GA17090@suse.de>
Message-ID: <20070727051235.GA26198@verge.net.au>

On Tue, Jul 10, 2007 at 10:23:16AM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-10 07:52]:
> > On Tue, Jul 03, 2007 at 06:12:07PM +0200, Bernhard Walle wrote:
> > > 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.
> > > 
> > 
> > Makes sense to me. No need to generate 64bit ELF headers on systems
> > having less than 4G of memory. gdb runs into issues with 64bit ELF headers
> > on 32bit machines.
> 
> Exaclty that was my point.
> 
> > I think we can avoid mixed case in "CoreType" and use something like
> > "coretype".
> 
> Of course:
> 
> ----
> 
> [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.

Sorry for being slow, I missed the patch earlier as it wasn't CCed to me.
I have applied it now.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/



From oomichi at mxs.nes.nec.co.jp  Fri Jul 27 05:12:43 2007
From: oomichi at mxs.nes.nec.co.jp (Ken'ichi Ohmichi)
Date: Fri, 27 Jul 2007 18:12:43 +0900
Subject: makedumpfile-1.1.5: Xen support
Message-ID: <20070727181243oomichi@mail.jp.nec.com>


Hi,

makedumpfile version 1.1.5 is released.
Please test it. Your opinions/comments are welcome.

Explanation of makedumpfile:
  To shorten the size of the dumpfile and the time of creating the
  dumpfile, makedumpfile copies only the necessary pages for analysis
  to the dumpfile from /proc/vmcore. You can specify the kind of
  unnecessary pages with dump_level. If you want to shorten the size
  further, enable the compression of the page data.


Changelog:
o Add a new feature that extracting the part of xen hypervisor and
  domain-0 from /proc/vmcore. In most cases under xen environment,
  it is enough to analyze a cause of system crash.
  The patch was provided by Itsuro Oda.
  Usage:
    # makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile

o Add a new option '-f' to overwrite existing dumpfile.
  The patch was provided by Bernhard Walle.

o Add a new option '--message-level "message-level"'.
  A user can specify multiple message types by setting the sum of each
  message type for "message-level". The default value is '7' (Print
  the progress indicator, common messages, and error messages).
   0: Print nothing.
   1: Print the progress indicator.
   2: Print common messages.
   4: Print error messages.
   8: Print debugging messages.

o Fix the problem that makedumpfile complains about overlapping memory
  segments. On some machines (ia64, discontigmem, and specific machine),
  one pglist_data has overlapping memory segments with other nodes.
  The existing makedumpfile complains about them, and it fails.
  To fix the problem, overlapping memory segments is separated by
  node_memblk. The idea was provided by Bernhard Walle.

o Rename makedumpfile's config file to "vmcoreinfo file".
  http://lists.infradead.org/pipermail/kexec/2007-July/000349.html

o Change the method for getting the kernel's OSRELEASE if generating
  a vmcoreinfo file. A new makedumpfile gets it from a vmlinux file.
  http://lists.infradead.org/pipermail/kexec/2007-July/000319.html

o Some cleanups
  - Cleanup the linux-version checking method.
    The patch was provided by Neil Horman.
  - Cleanup README for the building problem.
  - Cleanup the method for getting the offset of page.mapping.
  - Cleanup the method for reading a vmcoreinfo file.


You can download the latest makedumpfile(ver. 1.1.5) from the following URL.
Details of the change are written on the CVS page of the following site.
https://sourceforge.net/projects/makedumpfile/

Method of installation:
  You can compile the makedumpfile command as follows;
  1. "tar -zxvf makedumpfile-1.1.5.tar.gz"
  2. "cd makedumpfile"
  3. "make; make install"

Usage:
  makedumpfile [-c] [-E] [-d dump_level] [-x vmlinux] dump_mem dump_file

Example:
  If you want to exclude pages filled by zero, cache pages, user pages
  and free pages and to enable compression, please execute the following
  command.

  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile


Thanks
Ken'ichi Ohmichi


From nhorman at redhat.com  Fri Jul 27 07:14:28 2007
From: nhorman at redhat.com (Neil Horman)
Date: Fri, 27 Jul 2007 07:14:28 -0400
Subject: makedumpfile-1.1.5: Xen support
In-Reply-To: <20070727181243oomichi@mail.jp.nec.com>
References: <20070727181243oomichi@mail.jp.nec.com>
Message-ID: <20070727111428.GB25242@hmsendeavour.rdu.redhat.com>

On Fri, Jul 27, 2007 at 06:12:43PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi,
> 
> makedumpfile version 1.1.5 is released.
> Please test it. Your opinions/comments are welcome.
> 
> Explanation of makedumpfile:
>   To shorten the size of the dumpfile and the time of creating the
>   dumpfile, makedumpfile copies only the necessary pages for analysis
>   to the dumpfile from /proc/vmcore. You can specify the kind of
>   unnecessary pages with dump_level. If you want to shorten the size
>   further, enable the compression of the page data.
> 
Hey, this is too late to take into 5.1, but I'll hapily take it for 5.2
Neil



> 
> Changelog:
> o Add a new feature that extracting the part of xen hypervisor and
>   domain-0 from /proc/vmcore. In most cases under xen environment,
>   it is enough to analyze a cause of system crash.
>   The patch was provided by Itsuro Oda.
>   Usage:
>     # makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile
> 
> o Add a new option '-f' to overwrite existing dumpfile.
>   The patch was provided by Bernhard Walle.
> 
> o Add a new option '--message-level "message-level"'.
>   A user can specify multiple message types by setting the sum of each
>   message type for "message-level". The default value is '7' (Print
>   the progress indicator, common messages, and error messages).
>    0: Print nothing.
>    1: Print the progress indicator.
>    2: Print common messages.
>    4: Print error messages.
>    8: Print debugging messages.
> 
> o Fix the problem that makedumpfile complains about overlapping memory
>   segments. On some machines (ia64, discontigmem, and specific machine),
>   one pglist_data has overlapping memory segments with other nodes.
>   The existing makedumpfile complains about them, and it fails.
>   To fix the problem, overlapping memory segments is separated by
>   node_memblk. The idea was provided by Bernhard Walle.
> 
> o Rename makedumpfile's config file to "vmcoreinfo file".
>   http://lists.infradead.org/pipermail/kexec/2007-July/000349.html
> 
> o Change the method for getting the kernel's OSRELEASE if generating
>   a vmcoreinfo file. A new makedumpfile gets it from a vmlinux file.
>   http://lists.infradead.org/pipermail/kexec/2007-July/000319.html
> 
> o Some cleanups
>   - Cleanup the linux-version checking method.
>     The patch was provided by Neil Horman.
>   - Cleanup README for the building problem.
>   - Cleanup the method for getting the offset of page.mapping.
>   - Cleanup the method for reading a vmcoreinfo file.
> 
> 
> You can download the latest makedumpfile(ver. 1.1.5) from the following URL.
> Details of the change are written on the CVS page of the following site.
> https://sourceforge.net/projects/makedumpfile/
> 
> Method of installation:
>   You can compile the makedumpfile command as follows;
>   1. "tar -zxvf makedumpfile-1.1.5.tar.gz"
>   2. "cd makedumpfile"
>   3. "make; make install"
> 
> Usage:
>   makedumpfile [-c] [-E] [-d dump_level] [-x vmlinux] dump_mem dump_file
> 
> Example:
>   If you want to exclude pages filled by zero, cache pages, user pages
>   and free pages and to enable compression, please execute the following
>   command.
> 
>   # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile
> 
> 
> Thanks
> Ken'ichi Ohmichi

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/


From anderson at redhat.com  Fri Jul 27 12:18:08 2007
From: anderson at redhat.com (Dave Anderson)
Date: Fri, 27 Jul 2007 12:18:08 -0400
Subject: makedumpfile-1.1.5: Xen support
Message-ID: <46AA1AC0.2040702@redhat.com>


> Changelog:
> o Add a new feature that extracting the part of xen hypervisor and
>   domain-0 from /proc/vmcore. In most cases under xen environment,
>   it is enough to analyze a cause of system crash.
>   The patch was provided by Itsuro Oda.
>   Usage:
>     # makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile

Can you verify that the dumpfile created above is usable as both a
hypervisor dumpfile as well as a dom0 vmlinux dumpfile?  In other
words, can both of the following sessions be accomplished with the
resultant dumpfile?

  # crash xen-syms dumpfile

and:

  # crash vmlinux dumpfile

Thanks,
   Dave




From ebiederm at xmission.com  Fri Jul 27 21:58:56 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 27 Jul 2007 19:58:56 -0600
Subject: [BUG] i386 relocable kernel breakes /proc/kcore debugging
In-Reply-To: <200707280443.44048.maximlevitsky@gmail.com> (Maxim Levitsky's
	message of "Sat, 28 Jul 2007 04:43:43 +0300")
References: <200707280443.44048.maximlevitsky@gmail.com>
Message-ID: <m1fy39thjz.fsf@ebiederm.dsl.xmission.com>

Maxim Levitsky <maximlevitsky at gmail.com> writes:

> Hello,
>
> Today I noticed that gdb gets confused when I try to load a vmlinux image.
> gdb 'thinks' that all kernel symbols are below 0x80000000 , while they are at 
> 0xC000....
>
> Turning CONFIG_RELOCATABLE off fixes that, so I assume that is the reason for 
> that.
>
> I am using 2.6.23-rc1, although I don't think that older versions are better.
>
> Best regards,
> 	Maxim Levitsky

Weird.

Vivek could this be related to the problem of problematic core dumps we
were seeing earlier?

Eric


> PS: 
> This is what gdb says:

>
> (gdb) disassemble sys_open
> Dump of assembler code for function sys_open:
> 0x8026fa60 <sys_open+0>:        Cannot access memory at address 0x8026fa60
>
> While real address of sys_open is:
>
> [root at MAIN linux-2.6]# nm ./.obj/vmlinux |  grep sys_open
> .........
> c016ea60 T sys_open
>
> Strange, but gdb recordnizes the above address directly:
>
> (gdb) disassemble 0xc016ea60
> Dump of assembler code for function sys_open:
> 0xc016ea60 <sys_open+0>:        sub    $0x4,%esp
> 0xc016ea63 <sys_open+3>:        mov    0x10(%esp),%eax
> ...............


From bwalle at suse.de  Sat Jul 28 04:39:57 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Sat, 28 Jul 2007 10:39:57 +0200
Subject: [Crash-utility] ATA scsi driver misbehavior under kdump
	capture kernel
In-Reply-To: <46AA8338.mailxBAZ1JN3SV@eag09.americas.sgi.com>
References: <46AA8338.mailxBAZ1JN3SV@eag09.americas.sgi.com>
Message-ID: <20070728083956.GB21143@suse.de>

* Cliff Wickman <cpw at sgi.com> [2007-07-28 01:43]:
> I've run into a problem with the ATA SCSI disk driver when running in a
> kdump dump-capture kernel.
> 
> I'm running on 2-processor x86_64 box.  It has 2 scsi disks, /dev/sda and
> /dev/sdb
> 
> My kernel is 2.6.22, and built to be a dump capturing kernel loaded by kexec.
> When I boot this kernel by itself, it finds both sda and sdb.
> 
> But when it is loaded by kexec and booted on a panic it only finds sda.
> 
> Any ideas from those familiar with the ATA driver?

>From your previous posting I see that you're not using the ?irqpoll?
option for the capture kernel. One common problem for device drivers
is that interrupts are not delivered properly and ?irqpoll? prevents
that problem by calling each interrupt handler with each timer
interrupt.


Thanks,
   Bernhard


From oda at valinux.co.jp  Sat Jul 28 06:53:45 2007
From: oda at valinux.co.jp (Itsuro ODA)
Date: Sat, 28 Jul 2007 19:53:45 +0900 (JST)
Subject: makedumpfile-1.1.5: Xen support
In-Reply-To: <46AA1AC0.2040702@redhat.com>
References: <46AA1AC0.2040702@redhat.com>
Message-ID: <1181.219.4.192.46.1185620025.risu@secure.valinux.co.jp>

Hi Dave,

>> Changelog:
>> o Add a new feature that extracting the part of xen hypervisor and
>>   domain-0 from /proc/vmcore. In most cases under xen environment,
>>   it is enough to analyze a cause of system crash.
>>   The patch was provided by Itsuro Oda.
>>   Usage:
>>     # makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile
>
> Can you verify that the dumpfile created above is usable as both a
> hypervisor dumpfile as well as a dom0 vmlinux dumpfile?  In other
> words, can both of the following sessions be accomplished with the
> resultant dumpfile?
>
>   # crash xen-syms dumpfile
>
> and:
>
>   # crash vmlinux dumpfile
>

Yes.

Thanks.
-- 
Itsuro ODA <oda at valinux.co.jp>



From vgoyal at in.ibm.com  Mon Jul 30 05:16:24 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Mon, 30 Jul 2007 14:46:24 +0530
Subject: [patch] add kdump_after_notifier
In-Reply-To: <46A92E30.8070703@ah.jp.nec.com>
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com>
	<46A92E30.8070703@ah.jp.nec.com>
Message-ID: <20070730091624.GB6071@in.ibm.com>

On Fri, Jul 27, 2007 at 08:28:48AM +0900, Takenori Nagano wrote:
> Hi Vivek,
> 
> Vivek Goyal wrote:
> > On Thu, Jul 26, 2007 at 05:47:18PM +0200, Bernhard Walle wrote:
> >> * Vivek Goyal <vgoyal at in.ibm.com> [2007-07-26 17:44]:
> >>>> Of course, but that's why the patch doesn't change this by default but
> >>>> gives the user the choice.
> >>>>
> >>> What value will distro set it to by default?
> >> 0.
> >>
> >>> Can we be more specific in terms of functionality and code that exactly
> >>> what we are trying to do after panic?
> >> Well, KDB, but now everybody answers with ?not mainline -- doesn't
> >> count?.
> >>
> > 
> > That's true. Its not mainline. We had similar discussion in the past
> > also. I think we should allow only audited code to be run after panic().
> > Leaving it open to modules or unaudited code makes this solution
> > something like LKCD where whole lot of code used to run after the crash,
> > hence was unreliable.
> 
> It is *not* KDB specific problem. Please grep in mainline kernel. You can find
> some function using panic_notifier_list. (IPMI, softdog, heartbeat, etc...)
> My patch gives a chance to use kdump for panic_notifier user. It is good for
> kdump too, because kdump user goes to increase. :-)

I grepped for couple of items. Heartbeat functionality of for stopping
responding to service processsor in case of panic so that service processor
knows that system has crashed and it needs to reboot the machine. But if
somebody has configured and enabled kdump then we don't want service 
processor to stop responding to heartbeat otherwise service processor
will reboot the machine and we will not be able to capture the dump.

In case of detecting softlockup, panic notifier is used so that in case
of panic we don't want to flag other threads are not being scheduled and
it is a softlockup. In case of kdump this condition is not valid. Immediately
after kdump we will boot to next OS and previous kernel's context is wiped
off.

Can you please be specific what exactly is the problem you are facing? In
what situation is this call creating the problem?

> 
> Bernhard's idea (kdump uses panic_notifier) is very good for me. But it isn't
> good for kdump user, because they want to take a dump ASAP when panicked.
> 

This one is better than registering kdump as one of the users of a
panic_notifier() list. 

I think if there are any crash specific actions, they should be taken care
in next kernel while it is booting.

If something is really very time critical, and has to be done immediately
after panic (I am not sure how can one ensure that given the fact any number
of users can register on panic_notifier_list and you are not sure about your
order in the list and when one will get the control), then probably that
piece of code should be in kernel and called before crash_kexec().

What is that specific piece of action which you can't do in second kernel?

Eric, do you have any thoughts on this. I think these guys are referring
to failover problem where immediately after panic() they want to send
message to other node.

Thanks
Vivek


From fernando at oss.ntt.co.jp  Mon Jul 30 05:58:14 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Mon, 30 Jul 2007 18:58:14 +0900
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <20070720144302.2785e961.akpm@linux-foundation.org>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
	<1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
	<20070720144302.2785e961.akpm@linux-foundation.org>
Message-ID: <1185789494.9831.107.camel@sebastian.kern.oss.ntt.co.jp>

On Fri, 2007-07-20 at 14:43 -0700, Andrew Morton wrote: 
> On Fri, 20 Jul 2007 11:20:43 +0900
> Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:
> 
> > With the advent of kdump it is possible that device drivers receive
> > interrupts generated in the context of a previous kernel. Ideally
> > quiescing the underlying devices should suffice but not all drivers do
> > this, either because it is not possible or because they did not
> > contemplate this case. Thus drivers ought to be able to handle
> > interrupts coming in as soon as the interrupt handler is registered.
> > 
> > Signed-off-by: Fernando Luis Vazquez Cao <fernando at oss.ntt.co.jp>
> > ---
> > 
> > diff -urNp linux-2.6.22-orig/kernel/irq/manage.c linux-2.6.22-pendirq/kernel/irq/manage.c
> > --- linux-2.6.22-orig/kernel/irq/manage.c	2007-07-19 18:18:53.000000000 +0900
> > +++ linux-2.6.22-pendirq/kernel/irq/manage.c	2007-07-19 19:43:41.000000000 +0900
> > @@ -533,21 +533,32 @@ int request_irq(unsigned int irq, irq_ha
> >  
> >  	select_smp_affinity(irq);
> >  
> > -	if (irqflags & IRQF_SHARED) {
> > -		/*
> > -		 * It's a shared IRQ -- the driver ought to be prepared for it
> > -		 * to happen immediately, so let's make sure....
> > -		 * We do this before actually registering it, to make sure that
> > -		 * a 'real' IRQ doesn't run in parallel with our fake
> > -		 */
> > -		if (irqflags & IRQF_DISABLED) {
> > -			unsigned long flags;
> > +	/*
> > +	 * With the advent of kdump it possible that device drivers receive
> > +	 * interrupts generated in the context of a previous kernel. Ideally
> > +	 * quiescing the underlying devices should suffice but not all drivers
> > +	 * do this, either because it is not possible or because they did not
> > +	 * contemplate this case. Thus drivers ought to be able to handle
> > +	 * interrupts coming in as soon as the interrupt handler is registered.
> > +	 *
> > +	 * Besides, if it is a shared IRQ the driver ought to be prepared for
> > +	 * it to happen immediately too.
> > +	 *
> > +	 * We do this before actually registering it, to make sure that
> > +	 * a 'real' IRQ doesn't run in parallel with our fake.
> > +	 */
> > +	if (irqflags & IRQF_DISABLED) {
> > +		unsigned long flags;
> >  
> > -			local_irq_save(flags);
> > -			handler(irq, dev_id);
> > -			local_irq_restore(flags);
> > -		} else
> > -			handler(irq, dev_id);
> > +		local_irq_save(flags);
> > +		retval = handler(irq, dev_id);
> > +		local_irq_restore(flags);
> > +	} else
> > +		retval = handler(irq, dev_id);
> > +	if (retval == IRQ_HANDLED) {
> > +		printk(KERN_WARNING
> > +		       "%s (IRQ %d) handled a spurious interrupt\n",
> > +		       devname, irq);
> >  	}
> >  
> 
> This change means that we'll run the irq handler at request_irq()-time even
> for non-shared interrupts.
> 
> This is a bit of a worry.  See, shared-interrupt handlers are required to
> be able to cope with being called when their device isn't interrupting. 
> But nobody ever said that non-shared interrupt handlers need to be able to
> cope with that.
> 
> Hence these non-shared handlers are within their rights to emit warning
> printks, go BUG or accuse the operator of having busted hardware.
> 
> So bad things might happen because of this change.  And if they do, they
> will take a loooong time to be discovered, because non-shared interrupt
> handlers tend to dwell in crufty old drivers which not many people use.
> 
> So I'm wondering if it would be more prudent to only do all this for shared
> handlers?

I have been testing this patches on all my machines, which spans three
different architectures: i386, x86_64 (EM64T and Opteron), and ia64.

The good news is that nothing catastrophic happened and, in the process,
I managed to find some somewhat buggy interrupt handlers.

I will present a brief summary of my findings here. That said, I have to
admit that these are still preliminary results and have not had time to
dig deep into all the issues. I would like hear from you first.

- Test environment

-- x86_64 [EM64T]
   CPU: Intel(R) Xeon(TM) CPU 3.20GHz (2 cpus)
   SCSI: Adaptec AIC-7902B U320
   IDE: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller

-- x86_64 [Opteron]
   CPU: AMD Opteron(tm) Processor 240 (2 cpus)
   IDE: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)

-- ia64
   CPU: Itanium 2 Madison (2 cpus)
   SCSI: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual
Ultra320 SCSI
   IDE: Intel Corporation 82801DB (ICH4) IDE Controller

-- i386
   CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2 cpus)
   IDE: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev
02)

- Test results for i386

--i8042 (IRQ 12) handled a spurious interrupt -> i8042
The culprit here was the i8042_aux_test_irq interrupt handler
unconditionally returning IRQ_HANDLED despite being marked as
IRQF_SHARED. I submitted a fix and it is currently sitting in the
'for-linus' branch of Dmitry Torokhov's input tree (Dmitry, Alan,
Vojtech, thank you for reviewing the patch!).

-- eth0 (IRQ 16) handled a spurious interrupt -> e1000
The problem here is that the network card is active before it has been
assigned an interrupt line. This means that if the card detects an event
such as a link status change it will update the status register (ICR) by
setting the corresponding flag, even if request_irq has not been invoked
yet. In such a case, once the interrupt handler is set if a spurious
interrupt comes in it will be handled. The reason is that the handler
checks ICR to determine whether the underlying the device has generated
an interrupt or not, and the flag that indicates a link status change
will happen to be set.

I have sent a patch that clears the ICR before requesting an IRQ, but
according to Auke Kok there is a small window during which the device
could generate another link status change interrupt. I am looking for a
way to prevent the device from reacting to such events before an IRQ has
been allocated, but still do not know if it is possible.

-- rtc (IRQ 8) handled a spurious interrupt
-- parport0 (IRQ 7) handled a spurious interrupt
-- MPU401 UART (IRQ 10) handled a spurious interrupt
I have not looked into these three yet but it seems that in some cases
it is not possible to determine whether an interrupt has actually
occurred.

- Test results for x86_64 [EM64T]

-- i8042 (IRQ 12) handled a spurious interrupt -> i8042
Ditto.
-- eth0 (IRQ 54) handled a spurious interrupt -> e1000
Ditto.
-- rtc (IRQ 8) handled a spurious interrupt
Ditto.

- Test results for x86_64 [Opteron]
-- i8042 (IRQ 12) handled a spurious interrupt -> i8042
Ditto.
-- rtc (IRQ 8) handled a spurious interrupt
Ditto.
-- parport0 (IRQ 7) handled a spurious interrupt
Ditto.

- Test results for ia64
-- eth0 (IRQ 48) handled a spurious interrupt -> e1000
Ditto.

Besides these patches have exposed bugs in other people's machines too.
Valdis Kletnieks discovered a problem in his tpm driver and it seems
that the TPM guys are already looking into it.

- Conclusion

These patches can affect device drivers in several ways and, so far, I
have identified 5 possible scenarios:

  1. Shared handlers that behave as expected and ignore spurious
interrupts.
  2. Shared handlers that unconditionally handle any incoming interrupt.
  3. Shared handlers that cannot distinguish between interrupts that it
needs to handle and interrupts generated by other devices in certain
situations.
  4. Non-shared handlers that behave as expected and ignore spurious
interrupts.
  5. Drivers for legacy devices in which it is not possible to determine
whether a given interrupt has actually come from the underlying device.

Obviously, 1) and 4) are the ideal cases and (probably) the majority of
the drivers fall into this group.

2) means that the driver cannot cohabit harmoniously with other drivers
and it would end up handling any interrupt coming in from that interrupt
line regardless of its origin. i8042 used to be belong to this group,
but the aforementioned patch should have solved it.

Most devices have a interrupt pending bit in some port or an interrupt
cause register (ICR) that can be checked by the driver to determine what
interrupts it needs to handle. The problem is that some devices are
operational before request_irq has been called and react to external
events by updating the interrupt pending bit or the ICR. This means that
after actually registering the interrupt handler, any interrupt coming
in would be handled. 3) refers to such cases. By the way, the e1000
driver seems to be suffering this issue which causes the error message
above.

When it comes to 5) there is not much we can do. Sometimes you simply
cannot tell.

The bottom line is that we have to decide how two tackle 2), 3) and 5).
My gut feeling is that in most cases 2) and 3) constitute a bug, because
if the driver is not fixable then IRQF_SHARED should not have been set
in the first place. Regarding 5), there is no choice, so it seems we
would need to mark such drivers somehow (another possible solution would
be calling the interrupt handler from request_irq only when IRQF_SHARED
is set, because shared handlers should not be affected by this problem).

If we find drivers that are not fixable we should probably consider this
new behaviour on a per-driver basis, as Andrew suggested. This would
probably require passing a new flag into request_irq. Besides, when such
a driver is detected we should emit a warning that it may not work
properly in a kdump kernel.

I would appreciate your comments on this.

- Fernando



From anderson at redhat.com  Mon Jul 30 08:54:53 2007
From: anderson at redhat.com (Dave Anderson)
Date: Mon, 30 Jul 2007 08:54:53 -0400
Subject: makedumpfile-1.1.5: Xen support
In-Reply-To: <1181.219.4.192.46.1185620025.risu@secure.valinux.co.jp>
References: <46AA1AC0.2040702@redhat.com>
	<1181.219.4.192.46.1185620025.risu@secure.valinux.co.jp>
Message-ID: <46ADDF9D.4060704@redhat.com>

Itsuro ODA wrote:
> Hi Dave,
> 
> 
>>>Changelog:
>>>o Add a new feature that extracting the part of xen hypervisor and
>>>  domain-0 from /proc/vmcore. In most cases under xen environment,
>>>  it is enough to analyze a cause of system crash.
>>>  The patch was provided by Itsuro Oda.
>>>  Usage:
>>>    # makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile
>>
>>Can you verify that the dumpfile created above is usable as both a
>>hypervisor dumpfile as well as a dom0 vmlinux dumpfile?  In other
>>words, can both of the following sessions be accomplished with the
>>resultant dumpfile?
>>
>>  # crash xen-syms dumpfile
>>
>>and:
>>
>>  # crash vmlinux dumpfile
>>
> 
> 
> Yes.
> 
> Thanks.

Great -- thanks.

Is the "-d" dump_level option completely ignored, or can it
(without vmlinux awareness) recognize and skip zero-filled
pages?

Dave




From ebiederm at xmission.com  Mon Jul 30 09:42:59 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Mon, 30 Jul 2007 07:42:59 -0600
Subject: [patch] add kdump_after_notifier
In-Reply-To: <20070730091624.GB6071@in.ibm.com> (Vivek Goyal's message of
	"Mon, 30 Jul 2007 14:46:24 +0530")
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com> <20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com> <20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com> <46A92E30.8070703@ah.jp.nec.com>
	<20070730091624.GB6071@in.ibm.com>
Message-ID: <m16442vwgs.fsf@ebiederm.dsl.xmission.com>

Vivek Goyal <vgoyal at in.ibm.com> writes:

>> Bernhard's idea (kdump uses panic_notifier) is very good for me. But it isn't
>> good for kdump user, because they want to take a dump ASAP when panicked.
>> 
>
> This one is better than registering kdump as one of the users of a
> panic_notifier() list. 
>
> I think if there are any crash specific actions, they should be taken care
> in next kernel while it is booting.
>
> If something is really very time critical, and has to be done immediately
> after panic (I am not sure how can one ensure that given the fact any number
> of users can register on panic_notifier_list and you are not sure about your
> order in the list and when one will get the control), then probably that
> piece of code should be in kernel and called before crash_kexec().
>
> What is that specific piece of action which you can't do in second kernel?
>
> Eric, do you have any thoughts on this. I think these guys are referring
> to failover problem where immediately after panic() they want to send
> message to other node.

My thoughts are roughly the same as they were last time this was suggested.
I think adding a notifier to the kexec on panic path is a bad idea.
This functionality  sounds wrong, because it makes it hard to ensure
reliability of the kexec on panic code path.  We are still doing to
much on it as it stands. The working assumption on that code path
needs to be the kernel is broken. Anything else is just asking for
trouble.

Currently we do have a hook in place for code to be called. It is called
the purgatory section of /sbin/kexec.  And it's user space so you can
do whatever you want there.  Or you can wait until the second kernel
gets more fully booted.

If we really need to do something in the kernel we can patch the kernel
to make a function call from crash_kexec.  We don't need any notifiers
to do this.

A further problem with notifiers is they mess up the state we would
like to debug.  Which again makes them a problem.


So at least until a specific case is made for a specific piece of code
to get in I am totally opposed to the idea.

Eric


From akpm at linux-foundation.org  Mon Jul 30 14:22:23 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 30 Jul 2007 11:22:23 -0700
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <1185789494.9831.107.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
	<1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
	<20070720144302.2785e961.akpm@linux-foundation.org>
	<1185789494.9831.107.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <20070730112223.7b52cf63.akpm@linux-foundation.org>

On Mon, 30 Jul 2007 18:58:14 +0900
Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:

> > 
> > So bad things might happen because of this change.  And if they do, they
> > will take a loooong time to be discovered, because non-shared interrupt
> > handlers tend to dwell in crufty old drivers which not many people use.
> > 
> > So I'm wondering if it would be more prudent to only do all this for shared
> > handlers?
> 
> I have been testing this patches on all my machines, which spans three
> different architectures: i386, x86_64 (EM64T and Opteron), and ia64.
> 
> The good news is that nothing catastrophic happened and, in the process,
> I managed to find some somewhat buggy interrupt handlers.
> 
> I will present a brief summary of my findings here.

That's quite a lot of breakage for such a small sample of machines.  I do
suspect that if we were to merge this lot into mainline, all sorts of bad
stuff would happen.

otoh, as you point out, pretty much everthing which goes wrong is due to
incorrect or dubious driver behaviour, and there is value in weeding these
things out. 

But the problem with this process is that we're weeding things out at
runtime.  Some drivers don't get used by many people and users of some
architectures (esp embedded) tend to lag kernel.org by a long time.  So it
could be years before all the fallout from this change is finally wrapped
up.

> 
> If we find drivers that are not fixable we should probably consider this
> new behaviour on a per-driver basis, as Andrew suggested.

We haven't found any such yet, have we?

> This would
> probably require passing a new flag into request_irq. Besides, when such
> a driver is detected we should emit a warning that it may not work
> properly in a kdump kernel.
> 
> I would appreciate your comments on this.

Oh well, let's just keep maintaining it in -mm for now, gather more
information so that we can make a more informed decision later on.


From oda at valinux.co.jp  Mon Jul 30 18:19:48 2007
From: oda at valinux.co.jp (Itsuro ODA)
Date: Tue, 31 Jul 2007 07:19:48 +0900
Subject: makedumpfile-1.1.5: Xen support
In-Reply-To: <46ADDF9D.4060704@redhat.com>
References: <1181.219.4.192.46.1185620025.risu@secure.valinux.co.jp>
	<46ADDF9D.4060704@redhat.com>
Message-ID: <20070731071034.DBA9.ODA@valinux.co.jp>

Hi,

> Is the "-d" dump_level option completely ignored, or can it
> (without vmlinux awareness) recognize and skip zero-filled
> pages?

Yes, "-d" is ignored.

Hmm, adding to skip zero-filled pages is easy but I wonder
how effective it is ...

Thanks.
-- 
Itsuro ODA <oda at valinux.co.jp>



From cpw at sgi.com  Mon Jul 30 18:24:57 2007
From: cpw at sgi.com (Cliff Wickman)
Date: Mon, 30 Jul 2007 17:24:57 -0500
Subject: kdump not working under 2.6.22 kernel
Message-ID: <46AE6539.mailxBA21IP79F@eag09.americas.sgi.com>



I can't get kdump to work under a 2.6.22 kernel.
I'm running on 2-processor x86_64 box.  It has 2 scsi disks, /dev/sda and
/dev/sdb

Any capture kernel that I load with kexec and boot on a panic only finds sda.


the system kernel configuration has:
   CONFIG_DEBUG_INFO=y
   CONFIG_KEXEC=y
   CONFIG_SYSFS=y
   # CONFIG_RELOCATABLE
   CONFIG_SMP=y
   CONFIG_PHYSICAL_START=0x200000
   # CONFIG_CRASH_DUMP
   # CONFIG_PROC_VMCORE

kexec is executed as:

/sbin/kexec -p /boot/vmlinux-kdump --append=" 1 CRASH=1 root=/dev/sdb3 irqpoll console=ttyS0,38400n8 maxcpus=1 1" --initrd=/boot/initrd-kdump  --args-linux


The ATA scsi driver is not waiting to find the second disk.
I put some printk's into the driver and get this:

Standalone:
                                                   [nv_adma_error_handler]
cpw: ata_host_register probe port 1 (error_handler:ffffffff81348625)
cpw: ata_host_register call ata_port_probe
cpw: ata_host_register call ata_port_schedule
cpw: ata_host_register call ata_port_wait_eh
cpw: ata_port_wait_eh entered
cpw: ata_port_wait_eh, preparing to wait
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
cpw: ata_dev_configure entered
cpw: ata_dev_configure testing class
cpw: ata_dev_configure class is ATA_DEV_ATA
ata2.00: ATA-6: ST3200822AS, 3.01, max UDMA/133
ata2.00: 390721968 sectors, multi 16: LBA48
cpw: ata_dev_configure exiting
cpw: ata_dev_configure entered
cpw: ata_dev_configure testing class
cpw: ata_dev_configure class is ATA_DEV_ATA
cpw: ata_dev_configure exiting
cpw: ata_dev_set_mode printing:
ata2.00: configured for UDMA/133
cpw: ata_port_wait_eh, finished wait
cpw: ata_port_wait_eh exiting
cpw: ata_host_register done with probe port 1


When loaded with kexec and booted on a panic:

cpw: ata_host_register probe port 1 (error_handler:ffffffff81348625)
cpw: ata_host_register call ata_port_probe
cpw: ata_host_register call ata_port_schedule
cpw: ata_host_register call ata_port_wait_eh
cpw: ata_port_wait_eh entered
cpw: ata_port_wait_eh, preparing to wait
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
cpw: ata_port_wait_eh, finished wait
cpw: ata_port_wait_eh exiting
cpw: ata_host_register done with probe port 1

There is currently some device (udev?) problem with the 2.6.23 kernel. Could
this be related?

-Cliff Wickman
 SGI


From fernando at oss.ntt.co.jp  Mon Jul 30 22:25:26 2007
From: fernando at oss.ntt.co.jp (Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao)
Date: Tue, 31 Jul 2007 11:25:26 +0900
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <20070730112223.7b52cf63.akpm@linux-foundation.org>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
	<1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
	<20070720144302.2785e961.akpm@linux-foundation.org>
	<1185789494.9831.107.camel@sebastian.kern.oss.ntt.co.jp>
	<20070730112223.7b52cf63.akpm@linux-foundation.org>
Message-ID: <1185848726.23316.50.camel@sebastian.kern.oss.ntt.co.jp>

On Mon, 2007-07-30 at 11:22 -0700, Andrew Morton wrote: 
> On Mon, 30 Jul 2007 18:58:14 +0900
> Fernando Luis V__zquez Cao <fernando at oss.ntt.co.jp> wrote:
> 
> > > 
> > > So bad things might happen because of this change.  And if they do, they
> > > will take a loooong time to be discovered, because non-shared interrupt
> > > handlers tend to dwell in crufty old drivers which not many people use.
> > > 
> > > So I'm wondering if it would be more prudent to only do all this for shared
> > > handlers?
> > 
> > I have been testing this patches on all my machines, which spans three
> > different architectures: i386, x86_64 (EM64T and Opteron), and ia64.
> > 
> > The good news is that nothing catastrophic happened and, in the process,
> > I managed to find some somewhat buggy interrupt handlers.
> > 
> > I will present a brief summary of my findings here.
> 
> That's quite a lot of breakage for such a small sample of machines.  I do
> suspect that if we were to merge this lot into mainline, all sorts of bad
> stuff would happen.
Yup.

> otoh, as you point out, pretty much everthing which goes wrong is due to
> incorrect or dubious driver behaviour, and there is value in weeding these
> things out. 
> 
> But the problem with this process is that we're weeding things out at
> runtime.  Some drivers don't get used by many people and users of some
> architectures (esp embedded) tend to lag kernel.org by a long time.  So it
> could be years before all the fallout from this change is finally wrapped
> up.
Yes, that is a big concern. However, the same embedded people is
starting to use both kexec and kdump, so they may suffer the issues we
are trying to weed out anyway, even if these patches are not applied.
The difference is that with this new functionality it is possible to
catch potential problems relatively easily, because any incorrect
behaviour this may cause will be easily reproducible and, in most cases,
will reveal itself early at boot time.

As things stand now, I guess we will keep seeing occasional crashes and
strange behaviour in kexec-booted kernels, which in some cases will be
due to incorrect handling of spurious interrupts. Besides, such problems
are really difficult to reproduce because, commonly, we would need to
hit an obscure corner case.

> > If we find drivers that are not fixable we should probably consider this
> > new behaviour on a per-driver basis, as Andrew suggested.
> 
> We haven't found any such yet, have we?
Not yet, fortunately.

> > This would
> > probably require passing a new flag into request_irq. Besides, when such
> > a driver is detected we should emit a warning that it may not work
> > properly in a kdump kernel.
> > 
> > I would appreciate your comments on this.
> 
> Oh well, let's just keep maintaining it in -mm for now, gather more
> information so that we can make a more informed decision later on.
Makes sense. I will look into all the issues I have found so far, do
some more testing (I think a new approach is needed to speed up testing
of these issues...), and get back to you.

Thank you.

Fernando



From akpm at linux-foundation.org  Tue Jul 31 00:46:10 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 30 Jul 2007 21:46:10 -0700
Subject: [PATCH 2/2] Debug handling of early spurious interrupts
In-Reply-To: <1185848726.23316.50.camel@sebastian.kern.oss.ntt.co.jp>
References: <1184666997.5271.5.camel@sebastian.kern.oss.ntt.co.jp>
	<20070718154659.c8b5ffea.akpm@linux-foundation.org>
	<1184896459.27369.36.camel@sebastian.kern.oss.ntt.co.jp>
	<1184896944.27369.50.camel@sebastian.kern.oss.ntt.co.jp>
	<1184898043.28418.3.camel@sebastian.kern.oss.ntt.co.jp>
	<20070720144302.2785e961.akpm@linux-foundation.org>
	<1185789494.9831.107.camel@sebastian.kern.oss.ntt.co.jp>
	<20070730112223.7b52cf63.akpm@linux-foundation.org>
	<1185848726.23316.50.camel@sebastian.kern.oss.ntt.co.jp>
Message-ID: <20070730214610.9868cbe3.akpm@linux-foundation.org>

On Tue, 31 Jul 2007 11:25:26 +0900 Fernando Luis V?zquez Cao <fernando at oss.ntt.co.jp> wrote:

> > runtime.  Some drivers don't get used by many people and users of some
> > architectures (esp embedded) tend to lag kernel.org by a long time.  So it
> > could be years before all the fallout from this change is finally wrapped
> > up.
> Yes, that is a big concern. However, the same embedded people is
> starting to use both kexec and kdump, so they may suffer the issues we
> are trying to weed out anyway, even if these patches are not applied.
> The difference is that with this new functionality it is possible to
> catch potential problems relatively easily, because any incorrect
> behaviour this may cause will be easily reproducible and, in most cases,
> will reveal itself early at boot time.
> 
> As things stand now, I guess we will keep seeing occasional crashes and
> strange behaviour in kexec-booted kernels, which in some cases will be
> due to incorrect handling of spurious interrupts. Besides, such problems
> are really difficult to reproduce because, commonly, we would need to
> hit an obscure corner case.

Please have a think about what we can do to aid this debugging.  For
example, add an uncondtional printk into request_irq() for now which tells
us what irq is being registered - a print_symbol() of the irq_handler_t
would be pretty good, although I suspect there are a lot of interrupt
handlers with the same name..




From t-nagano at ah.jp.nec.com  Tue Jul 31 01:55:44 2007
From: t-nagano at ah.jp.nec.com (Takenori Nagano)
Date: Tue, 31 Jul 2007 14:55:44 +0900
Subject: [patch] add kdump_after_notifier
In-Reply-To: <m16442vwgs.fsf@ebiederm.dsl.xmission.com>
References: <469F55D0.4050203@ah.jp.nec.com>
	<20070726140702.GA8949@suse.de>	<20070726153240.GA15969@in.ibm.com>
	<20070726153440.GA19095@suse.de>	<20070726154415.GB15969@in.ibm.com>
	<20070726154718.GA25561@suse.de>	<20070726155444.GC15969@in.ibm.com>
	<46A92E30.8070703@ah.jp.nec.com>	<20070730091624.GB6071@in.ibm.com>
	<m16442vwgs.fsf@ebiederm.dsl.xmission.com>
Message-ID: <46AECEE0.3000307@ah.jp.nec.com>

Eric W. Biederman wrote:
> Vivek Goyal <vgoyal at in.ibm.com> writes:
> 
>>> Bernhard's idea (kdump uses panic_notifier) is very good for me. But it isn't
>>> good for kdump user, because they want to take a dump ASAP when panicked.
>>>
>> This one is better than registering kdump as one of the users of a
>> panic_notifier() list. 
>>
>> I think if there are any crash specific actions, they should be taken care
>> in next kernel while it is booting.
>>
>> If something is really very time critical, and has to be done immediately
>> after panic (I am not sure how can one ensure that given the fact any number
>> of users can register on panic_notifier_list and you are not sure about your
>> order in the list and when one will get the control), then probably that
>> piece of code should be in kernel and called before crash_kexec().
>>
>> What is that specific piece of action which you can't do in second kernel?
>>
>> Eric, do you have any thoughts on this. I think these guys are referring
>> to failover problem where immediately after panic() they want to send
>> message to other node.
> 
> My thoughts are roughly the same as they were last time this was suggested.
> I think adding a notifier to the kexec on panic path is a bad idea.
> This functionality  sounds wrong, because it makes it hard to ensure
> reliability of the kexec on panic code path.  We are still doing to
> much on it as it stands. The working assumption on that code path
> needs to be the kernel is broken. Anything else is just asking for
> trouble.
> 
> Currently we do have a hook in place for code to be called. It is called
> the purgatory section of /sbin/kexec.  And it's user space so you can
> do whatever you want there.  Or you can wait until the second kernel
> gets more fully booted.
> 
> If we really need to do something in the kernel we can patch the kernel
> to make a function call from crash_kexec.  We don't need any notifiers
> to do this.
> 
> A further problem with notifiers is they mess up the state we would
> like to debug.  Which again makes them a problem.
> 
> 
> So at least until a specific case is made for a specific piece of code
> to get in I am totally opposed to the idea.

Hi all,

IMHO, most users don't use kdump, kdump users are only kernel developers and
enterprise users. I think enterprise users want the notifier function, because
they use some driver and software (hardware monitering driver, clustering
software, heartbeat driver, etc...) to raise their system availability.

Some popular distributers added the dump function to their own kernel. We can
use panic_notifier on LKCD (http://lkcd.sourceforge.net/), and diskdump
(http://sourceforge.net/projects/lkdump) provides own notifier function
disk_dump_notifier.

Now, kdump was merged mainline kernel. Then some distributers chose kdump.
I think kdump is greater than other dump function, but kdump has no notifier
function. This is a large problem for enterprise users.

Solutions
 1: my patch
 2: Bernhard's idea
 3: add kdump_notifier_list

I think my patch is better than other solutions, because it has only very few
impact. Vivek, Eric, how do you think?

Thanks.



From ebiederm at xmission.com  Tue Jul 31 02:53:54 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 31 Jul 2007 00:53:54 -0600
Subject: [patch] add kdump_after_notifier
In-Reply-To: <46AECEE0.3000307@ah.jp.nec.com> (Takenori Nagano's message of
	"Tue, 31 Jul 2007 14:55:44 +0900")
References: <469F55D0.4050203@ah.jp.nec.com> <20070726140702.GA8949@suse.de>
	<20070726153240.GA15969@in.ibm.com> <20070726153440.GA19095@suse.de>
	<20070726154415.GB15969@in.ibm.com> <20070726154718.GA25561@suse.de>
	<20070726155444.GC15969@in.ibm.com> <46A92E30.8070703@ah.jp.nec.com>
	<20070730091624.GB6071@in.ibm.com>
	<m16442vwgs.fsf@ebiederm.dsl.xmission.com>
	<46AECEE0.3000307@ah.jp.nec.com>
Message-ID: <m1fy35t665.fsf@ebiederm.dsl.xmission.com>

Takenori Nagano <t-nagano at ah.jp.nec.com> writes:
>
> Hi all,
>
> IMHO, most users don't use kdump, kdump users are only kernel developers and
> enterprise users. 

Not at all.  So far the only kdump related bug report I have seen has
been from fedora Core.

> think enterprise users want the notifier function, because
> they use some driver and software (hardware monitering driver, clustering
> software, heartbeat driver, etc...) to raise their system availability.

Which users want this?  Specifics are needed here not hand waving.
In particular why can't the use the existing hooks that are already
in place.

> Some popular distributers added the dump function to their own kernel. We can
> use panic_notifier on LKCD (http://lkcd.sourceforge.net/), and diskdump
> (http://sourceforge.net/projects/lkdump) provides own notifier function
> disk_dump_notifier.
>
> Now, kdump was merged mainline kernel. Then some distributers chose kdump.
> I think kdump is greater than other dump function, but kdump has no notifier
> function. This is a large problem for enterprise users.

Why?  If this is a large problem we should have people that are willing
to have patches with users of this notifier.

> Solutions
>  1: my patch
>  2: Bernhard's idea
>  3: add kdump_notifier_list

I think you are solving a non-problem.  And the more I get hand waving
the more I think this. 

> I think my patch is better than other solutions, because it has only very few
> impact. Vivek, Eric, how do you think?

No.  The problem with your patch is that it doesn't have a code
impact.  We need to see who is using this and why.

Because you are trying to hide what is going on your code has
a tremendous maintenance and review burden.  I think any hook has a
tremendous maintenance and review burden.  Especially since the people
who want this absolutely refuse to publish their code.

If it is some proprietary solution that needs this and can not
withstand a code review it is absolutely the wrong thing to have
on this path.

The answer is no, and it isn't even worth talking about
until the code for some real users shows up.

Adding a notifier violates a fundamental assumption of
the code path.  The assumption is that the entire kernel
is broken, and you want me to follow a broken pointer
to broken code?

We already have so much code on that code path it is almost
impossible to test and review thoroughly and you want to
add more crap?

My apologies about my tone but I'm very annoyed at the direction of
all of this conversation, please don't try and avoid showing the
users.  Please let's make it upfront.

Eric


From pavel at ucw.cz  Tue Jul 31 06:09:08 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 12:09:08 +0200
Subject: kexec/kdump: docs fix, stale urls?
Message-ID: <20070731100908.GD3462@elf.ucw.cz>

Hi!

This fixes few typos in kdump.txt. (Please check, I'm not native
speaker). 

Also, the urls pointed out in kdump.txt seem a bit old, are there
better pointers these days?

								Pavel

--- 

This fixes few typos in kdump.txt.

Signed-off-by: Pavel Machek <pavel at suse.cz>

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index eb60087..faf0e27 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -69,7 +69,7 @@ http://www.kernel.org/pub/linux/kernel/p
 
 This is a symlink to the latest version, which at the time of writing is
 20061214, the only release of kexec-tools-testing so far. As other versions
-are made released, the older onese will remain available at
+are released, the older ones will remain available at
 http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
 
 Note: Latest kexec-tools-testing git tree is available at

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From vgoyal at in.ibm.com  Tue Jul 31 06:30:01 2007
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Tue, 31 Jul 2007 16:00:01 +0530
Subject: kexec/kdump: docs fix, stale urls?
In-Reply-To: <20070731100908.GD3462@elf.ucw.cz>
References: <20070731100908.GD3462@elf.ucw.cz>
Message-ID: <20070731103001.GD29531@in.ibm.com>

On Tue, Jul 31, 2007 at 12:09:08PM +0200, Pavel Machek wrote:
> Hi!
> 
> This fixes few typos in kdump.txt. (Please check, I'm not native
> speaker). 
> 
> Also, the urls pointed out in kdump.txt seem a bit old, are there
> better pointers these days?
> 
> 								Pavel
> 
> --- 
> 
> This fixes few typos in kdump.txt.
> 
> Signed-off-by: Pavel Machek <pavel at suse.cz>
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index eb60087..faf0e27 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -69,7 +69,7 @@ http://www.kernel.org/pub/linux/kernel/p
> 
>  This is a symlink to the latest version, which at the time of writing is
>  20061214, the only release of kexec-tools-testing so far. As other versions
> -are made released, the older onese will remain available at
> +are released, the older ones will remain available at
>  http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
> 

This URL is still current. 

Thanks
Vivek


From bwalle at suse.de  Tue Jul 31 14:51:25 2007
From: bwalle at suse.de (Bernhard Walle)
Date: Tue, 31 Jul 2007 20:51:25 +0200
Subject: kexec/kdump: docs fix, stale urls?
In-Reply-To: <20070731103001.GD29531@in.ibm.com>
References: <20070731100908.GD3462@elf.ucw.cz>
	<20070731103001.GD29531@in.ibm.com>
Message-ID: <20070731185124.GA12267@suse.de>

* Vivek Goyal <vgoyal at in.ibm.com> [2007-07-31 12:30]:
> 
> This URL is still current. 

Maybe you can add the git tree at
http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-testing.git
which is very up to date.


Thanks,
   Bernhard


From subrata at linux.vnet.ibm.com  Tue Jul 31 01:10:51 2007
From: subrata at linux.vnet.ibm.com (Subrata Modak)
Date: Tue, 31 Jul 2007 10:40:51 +0530
Subject: [ANNOUNCE] The Linux Test Project has been Released for JULY 2007
Message-ID: <46AEC45B.2040405@linux.vnet.ibm.com>

Dear All,

The Linux Test Project test suite <http://www.linuxtestproject.org> has 
been released for the month of JULY 2007. The latest version of the 
test-suite contains 3000+ tests for the Linux OS and can be found at 
http://prdownloads.sourceforge.net/ltp/ltp-full-20070731.tgz?download. 
Latest happenings in LTP can be found at 
http://ltp.sourceforge.net/wiki/ and 
http://ltp.sourceforge.net/wikiArchives.php. 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_POSIX_TESTSUITE to version 1.5.2 ,
* KDUMP testcases getting more matured,
* 'fsx-linux' testcase for "Distributed filesystem coherency" being made 
uniform across LTP,
* Gcov-kernel patch for 2.6.22, and other updation for LCOV
* Many more patches to fix Bugs/anomalies in various test cases

Note(s) from the Maintainer:
Work has been initiated to improve LTP log formats, fix false positives 
and add new test-cases to LTP. We are also in discussion to start 
*LTP-DASH-MM* tree within LTP, which would incorporate test-cases for 
newly developed/built Kernel features. The Idea is to merge the same 
test-cases into LTP once those features becomes part of the main kernel. 
Would request your suggestions on this too.


We encourage the community to post results to ltp-results at lists.sf.net, 
and patches, new tests, bugs or comments/questions to 
ltp-list at lists.sf.net,
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=103382 (for 
New Bug(s)),
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=303382 (for 
New Patch(s)),
http://sourceforge.net/tracker/?func=add&group_id=3382&atid=353382 (for 
New Feature Request(s))

Please also see the ChangeLog Below (JULY 2007):

1)  Log Message: lcov: preparations for new release by 
"oberpapr at users.sourceforge.net"
- updated CHANGES file
- added compat-libtool + no-compat-libtool option
- changed libtool default to on (due to popular request)
- added checksum option
- changed checksum default to off (to reduce cpu time + file size)
- added geninfo_checksum option to lcovrc, deprecated geninfo_no_checksum
- added geninfo_compat_libtool option to lcovrc
- minor update of README file
File(s) Affected:
ltp/utils/analysis/lcov/CHANGES
ltp/utils/analysis/lcov/README
ltp/utils/analysis/lcov/lcovrc
ltp/utils/analysis/lcov/bin/geninfo
ltp/utils/analysis/lcov/bin/lcov

2)  Log Message: update manpage by "oberpapr at users.sourceforge.net"
File(s) Affected:
ltp/utils/analysis/lcov/man/lcov.1

3)  Log Message: "sachinp at in.ibm.com" has fixed a probe point definition 
from 'll_rw_lock' to 'll_rw_block'
File(s) Affected:
ltp/testcases/kdump/susetools/lkdtm_mod/lkdtm.c

4)  Log Message: man page update by "oberpapr at users.sourceforge.net"
File(s) Affected:
ltp/utils/analysis/lcov/man/genhtml.1
ltp/utils/analysis/lcov/man/geninfo.1
ltp/utils/analysis/lcov/man/lcov.1

5)  Log Message: lcov: another update in preparation for a new release 
by "oberpapr at users.sourceforge.net"
File(s) Affected:
ltp/utils/analysis/lcov/bin/lcov
ltp/utils/analysis/lcov/man/lcovrc.5
ltp/utils/analysis/lcov/CHANGES
ltp/utils/analysis/lcov/lcovrc

6)  Log Message: fixed bug that would not delete .gcda files when using 
-z, by "oberpapr at users.sourceforge.net"
File(s) Affected:
ltp/utils/analysis/lcov/CHANGES
ltp/utils/analysis/lcov/bin/lcov

7)  Log Message: lcov: - add new option --initial to get zero coverage 
data from graph files by "oberpapr at users.sourceforge.net"
File(s) Affected:
ltp/utils/analysis/lcov/CHANGES
ltp/utils/analysis/lcov/bin/geninfo
ltp/utils/analysis/lcov/bin/lcov
ltp/utils/analysis/lcov/man/geninfo.1
ltp/utils/analysis/lcov/man/lcov.1

8)  Log Message: "carmelo.amoroso at st.com" fixed the anomaly when "SHLBA 
!= getpagesize()", like in SH architecture
File(s) Affected:
ltp/testcases/kernel/mem/shmt/shmt09.c

9)  Log Message: "hdeller at users.sf.net" fixed unitialized variable 
useage in "lseek09" testcase
File(s) Affected:
ltp/testcases/kernel/syscalls/lseek/lseek09.c

10) Log Message: "naveenspen at gmail.com" pointed out that 
syslog_cmd="/etc/init.d/syslog" should be used irrespective of any Distro
File(s) Affected:
ltp/testcases/kernel/syscalls/syslog/syslog01
ltp/testcases/kernel/syscalls/syslog/syslog02
ltp/testcases/kernel/syscalls/syslog/syslog03
ltp/testcases/kernel/syscalls/syslog/syslog04
ltp/testcases/kernel/syscalls/syslog/syslog05
ltp/testcases/kernel/syscalls/syslog/syslog06
ltp/testcases/kernel/syscalls/syslog/syslog07
ltp/testcases/kernel/syscalls/syslog/syslog08
ltp/testcases/kernel/syscalls/syslog/syslog09
ltp/testcases/kernel/syscalls/syslog/syslog10

11) Log Message: "rsalveti at linux.vnet.ibm.com" pointed out to have same 
"fsx-linux" testcase for "fs", "ltp-aiodio" and "nfs"
File(s) Affected:
ltp/testcases/kernel/io/ltp-aiodio/fsx-linux.c
ltp/testcases/network/nfs/fsx-linux/fsx-linux.c

12) Log Message: Randy Dunlap writes: Fix printf format warnings
File(s) Affected:
ltp/testcases/network/stress/ns-tools/Makefile
ltp/testcases/network/stress/ns-tools/ns-igmp_querier.c
ltp/testcases/network/stress/ns-tools/ns-mcast_join.c
ltp/testcases/network/stress/ns-tools/ns-mcast_receiver.c
ltp/testcases/network/stress/ns-tools/ns-tcpserver.c

13) Log Message: getsockopt() takes a socklen_t, not an int, as its optlen
File(s) Affected:
ltp/testcases/network/stress/ns-tools/ns-tcpclient.c
ltp/testcases/network/stress/ns-tools/ns-tcpserver.c
ltp/testcases/network/stress/ns-tools/ns-udpserver.c

14) Log Message: cleanup file
File(s) Affected:
ltp/testcases/kernel/syscalls/gethostid/gethostid01.c

15) Log Message: back out uclinux changes to something that doesnt spit 
warnings as reported by Randy Dunlap
File(s) Affected:
ltp/testcases/kernel/syscalls/gethostid/gethostid01.c

16) Log Message: fixup gcc warnings by removing silly pieces of code
File(s) Affected:
ltp/testcases/kernel/mem/mtest06/mmap1.c
ltp/testcases/kernel/mem/mtest06/mmap2.c
ltp/testcases/kernel/mem/mtest06/mmap3.c
ltp/testcases/kernel/mem/mtest06/shmat1.c

17) Log Message: Randy Dunlap writes: Convert mmap1 to use standard test 
results output format. Correct several typos.
File(s) Affected:
ltp/testcases/kernel/mem/mtest06/Makefile
ltp/testcases/kernel/mem/mtest06/mmap1.c

18) Log Message: gcov-kernel: adding gcov-kernel patch for 2.6.22
File(s) Addes:
ltp/utils/analysis/gcov-kernel/linux-2.6.22-gcov-arm-hack.patch
ltp/utils/analysis/gcov-kernel/linux-2.6.22-gcov.patch

19) Log Message: [1754301] Helge Deller writes: mark hppa/parisc as 
expecting a segv as well
File(s) Affected:
ltp/testcases/kernel/syscalls/mmap/mmap03.c

20) Log Message: Randy Dunlap writes: convert output to match the 
standard LTP output
File(s) Affected:
ltp/testcases/kernel/fs/linktest/linktest.pl

21) Log Message: close stdout to remove noise
File(s) Affected:
ltp/testcases/kernel/mem/mtest05/dummy.c

22) Log Message: Randy Dunlap writes: Convert mmstress to use the 
standard results format
File(s) Affected:
ltp/testcases/kernel/mem/mtest05/Makefile
ltp/testcases/kernel/mem/mtest05/mmstress.c

23) Log Message: "rsalveti at linux.vnet.ibm.com" updated the contact 
information at ltp-howto doc
File(s) Affected:
ltp/doc/ltp-howto.lyx
ltp/doc/ltp-howto.txt

24) Log Message: "rsalveti at linux.vnet.ibm.com" wants to update this with 
kernel/fs/fsstress/fsstress.c
File(s) Affected:
ltp/testcases/network/nfs/nfs_fsstress/fsstress.c

25) Log Message: "suzuki at in.ibm.com" added SIGNAL and Address Fault 
handling capability for all architectures
File(s) Affected:
ltp/testcases/kernel/mem/mtest06/mmap1.c

26) Log Message: "rsalveti at linux.vnet.ibm.com" added more options to 
'runltp'
File(s) Affected:
ltp/runltp
ltp/doc/man1/pan.1
ltp/pan/pan.c

27) Log Message: Upgrade to Posix Testsuite 1.5.2
File(s) Affected/Added:
ltp/testcases/open_posix_testsuite

28) Log Message: Fixing Proper Freeing of Memory Chunks
File(s) Affected:
ltp/tools/genload/stress.c

Happy testing,
Regards--
Subrata Modak,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/kexec/attachments/20070731/76bd1af4/attachment-0001.html 

From pavel at ucw.cz  Tue Jul 31 05:10:04 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 11:10:04 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184483593.1898.98.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
Message-ID: <20070731091004.GA2022@elf.ucw.cz>

Hi!


> Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
> ===================================================================
> --- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c	2007-07-08 23:00:25.000000000 +0800
> +++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c	2007-07-14 17:06:45.000000000 +0800
> @@ -428,6 +428,29 @@
>  	return 0;
>  }
>  
> +/* Adds the kexec_backup= command line parameter to command line. */
> +static int cmdline_add_backup(char *cmdline, unsigned long addr)
> +{
> +	int cmdlen, len, align = 1024;
> +	char str[30], *ptr;
> +
> +	/* Passing in kexec_backup=xxxK format. Saves space required
> +	 * in cmdline. Ensure 1K alignment*/
> +	if (addr%align)
> +		return -1;
> +	addr = addr/align;
> +	ptr = str;
> +	strcpy(str, " kexec_backup=");
> +	ptr += strlen(str);
> +	ultoa(addr, ptr);
> +	strcat(str, "K");
> +	len = strlen(str);
> +	cmdlen = strlen(cmdline) + len;
> +	if (cmdlen > (COMMAND_LINE_SIZE - 1))
> +		die("Command line overflow\n");
> +	strcat(cmdline, str);
> +	return 0;
> +}

This part did not apply for me -- it seems crashdump related and I did
not have that applied. Is it critical?

> Index: kexec-tools-1.101/kexec/kexec.c
> ===================================================================
> --- kexec-tools-1.101.orig/kexec/kexec.c	2007-07-14 16:57:26.000000000 +0800
> +++ kexec-tools-1.101/kexec/kexec.c	2007-07-14 21:04:51.000000000 +0800
> @@ -660,6 +660,17 @@
>  	return -1;
>  }
>  
> +/*
> + *	Jump to the new kernel
> + */
> +static int my_jump(void)
> +{
> +	int result;
> +
> +	result = kexec_jump();
> +	return result;
> +}
> +
>  static void version(void)
>  {
>  	printf("kexec " VERSION " released " RELEASE_DATE "\n");
> @@ -683,6 +694,7 @@
>  		" -p, --load-panic     Load the new kernel for use on panic.\n"
>  		" -u, --unload         Unload the current kexec target kernel.\n"
>  		" -e, --exec           Execute a currently loaded kernel.\n"
> +		" -j, --jump           Jump to a currently loaded kernel or jump back to the previous kernel.\n"
>  		" -t, --type=TYPE      Specify the new kernel is of this type.\n"
>  		"     --mem-min=<addr> Specify the lowest memory addres to load code into.\n"
>  		"     --mem-max=<addr> Specify the highest memory addres to load code into.\n"
> @@ -715,6 +727,7 @@
>  {
>  	int do_load = 1;
>  	int do_exec = 0;
> +	int do_jump = 0;
>  	int do_shutdown = 1;
>  	int do_sync = 1;
>  	int do_ifdown = 0;
> @@ -768,6 +781,14 @@
>  			do_ifdown = 1;
>  			do_exec = 1;
>  			break;
> +		case OPT_JUMP:
> +			do_load = 0;
> +			do_shutdown = 0;
> +			do_sync = 1;
> +			do_ifdown = 0;
> +			do_exec = 0;
> +			do_jump = 1;
> +			break;
>  		case OPT_TYPE:
>  			type = optarg;
>  			break;
> @@ -833,6 +854,9 @@
>  	if ((result == 0) && do_exec) {
>  		result = my_exec();
>  	}
> +	if ((result == 0) && do_jump) {
> +		result = my_jump();
> +	}
>  

Well, it may be nice to print something to the user he. kexec
-j does nothing, and does not print error message in case something is
wrong...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From ying.huang at intel.com  Tue Jul 31 05:25:24 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Tue, 31 Jul 2007 17:25:24 +0800
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <20070731091004.GA2022@elf.ucw.cz>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731091004.GA2022@elf.ucw.cz>
Message-ID: <1185873924.23149.86.camel@caritas-dev.intel.com>

On Tue, 2007-07-31 at 11:10 +0200, Pavel Machek wrote:
> > Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
> > ===================================================================
> > --- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c	2007-07-08 23:00:25.000000000 +0800
> > +++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c	2007-07-14 17:06:45.000000000 +0800
> > @@ -428,6 +428,29 @@
> >  	return 0;
> >  }
> >  
> > +/* Adds the kexec_backup= command line parameter to command line. */
> > +static int cmdline_add_backup(char *cmdline, unsigned long addr)
> > +{
> > +	int cmdlen, len, align = 1024;
> > +	char str[30], *ptr;
> > +
> > +	/* Passing in kexec_backup=xxxK format. Saves space required
> > +	 * in cmdline. Ensure 1K alignment*/
> > +	if (addr%align)
> > +		return -1;
> > +	addr = addr/align;
> > +	ptr = str;
> > +	strcpy(str, " kexec_backup=");
> > +	ptr += strlen(str);
> > +	ultoa(addr, ptr);
> > +	strcat(str, "K");
> > +	len = strlen(str);
> > +	cmdlen = strlen(cmdline) + len;
> > +	if (cmdlen > (COMMAND_LINE_SIZE - 1))
> > +		die("Command line overflow\n");
> > +	strcat(cmdline, str);
> > +	return 0;
> > +}
> 
> This part did not apply for me -- it seems crashdump related and I did
> not have that applied. Is it critical?

This is needed for kexec_jump to work properly. Which version of
kexec-tools do you use? This patch is against 1.101. The kdump patch
must be applied before this patch is applied.

> > Index: kexec-tools-1.101/kexec/kexec.c
> > ===================================================================
> > --- kexec-tools-1.101.orig/kexec/kexec.c	2007-07-14 16:57:26.000000000 +0800
> > +++ kexec-tools-1.101/kexec/kexec.c	2007-07-14 21:04:51.000000000 +0800
> > @@ -660,6 +660,17 @@
> >  	return -1;
> >  }
> >  
> > +/*
> > + *	Jump to the new kernel
> > + */
> > +static int my_jump(void)
> > +{
> > +	int result;
> > +
> > +	result = kexec_jump();
> > +	return result;
> > +}
> > +
> >  static void version(void)
> >  {
> >  	printf("kexec " VERSION " released " RELEASE_DATE "\n");
> > @@ -683,6 +694,7 @@
> >  		" -p, --load-panic     Load the new kernel for use on panic.\n"
> >  		" -u, --unload         Unload the current kexec target kernel.\n"
> >  		" -e, --exec           Execute a currently loaded kernel.\n"
> > +		" -j, --jump           Jump to a currently loaded kernel or jump back to the previous kernel.\n"
> >  		" -t, --type=TYPE      Specify the new kernel is of this type.\n"
> >  		"     --mem-min=<addr> Specify the lowest memory addres to load code into.\n"
> >  		"     --mem-max=<addr> Specify the highest memory addres to load code into.\n"
> > @@ -715,6 +727,7 @@
> >  {
> >  	int do_load = 1;
> >  	int do_exec = 0;
> > +	int do_jump = 0;
> >  	int do_shutdown = 1;
> >  	int do_sync = 1;
> >  	int do_ifdown = 0;
> > @@ -768,6 +781,14 @@
> >  			do_ifdown = 1;
> >  			do_exec = 1;
> >  			break;
> > +		case OPT_JUMP:
> > +			do_load = 0;
> > +			do_shutdown = 0;
> > +			do_sync = 1;
> > +			do_ifdown = 0;
> > +			do_exec = 0;
> > +			do_jump = 1;
> > +			break;
> >  		case OPT_TYPE:
> >  			type = optarg;
> >  			break;
> > @@ -833,6 +854,9 @@
> >  	if ((result == 0) && do_exec) {
> >  		result = my_exec();
> >  	}
> > +	if ((result == 0) && do_jump) {
> > +		result = my_jump();
> > +	}
> >  
> 
> Well, it may be nice to print something to the user he. kexec
> -j does nothing, and does not print error message in case something is
> wrong...

Yes. At least some message should be printed in case something is wrong.
I will fix it in the next version.

Best Regards,
Huang Ying


From pavel at ucw.cz  Tue Jul 31 05:51:01 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 11:51:01 +0200
Subject: [PATH 1/1] Kexec jump - v2 - kexec jump
In-Reply-To: <1184483639.1898.99.camel@caritas-dev.intel.com>
References: <1184483639.1898.99.camel@caritas-dev.intel.com>
Message-ID: <20070731095101.GA1774@elf.ucw.cz>

Hi!

> This patch implement the functionality of jumping from kexeced kernel
> to original kernel.
> 
> A new reboot command named LINUX_REBOOT_CMD_KJUMP is defined to
> trigger the jumping to (executing) the new kernel or jumping back to
> the original kernel.

Could we get two reboot commands? Exec loaded kernel seems to be quite
different operation than "jump back".

How do I test these patches? kexec -p <bzImage>, then kexec -j?


> +static unsigned long kexec_backup_addr = ~0UL;
> +
> +/* kexec_backup= specifies the location of backuped 0~640k memory of
> + * crashed kernel.
> + */
> +static int __init parse_kexec_backup(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	kexec_backup_addr = memparse(arg, &arg);
> +	return 0;
> +}
> +early_param("kexec_backup", parse_kexec_backup);

New kernel parameters should be documented. (Plus I do not know how to
use this one, please help :-).


> +int kexec_flags;
> +
> +static unsigned long kexec_jump_buf_pfn;
> +
> +static int __init parse_kexec_jump_buf_pfn(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	kexec_jump_buf_pfn = memparse(arg, &arg);
> +	kexec_flags |= KEXEC_FLAGS_IS_KEXECED_KERNEL;
> +	return 0;
> +}
> +early_param("kexec_jump_buf_pfn", parse_kexec_jump_buf_pfn);

This one should be documented, too, I'd guess. (Is that internal,
kernel-to-kernel communication?)

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at ucw.cz  Tue Jul 31 07:04:58 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 13:04:58 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1184483593.1898.98.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
Message-ID: <20070731110458.GA1777@elf.ucw.cz>

Hi!

> 3. Boot kernel compiled for normal usage, the reserved crash kernel
>    memory region must be added to kernel command line as following:
> 
>    crashkernel=<XX>M@<XX>M
> 
>    Where, <XX> should be replaced by the real memory size and
> position.

I used crashkernel=64M at 64M .


> 4. Load kernel compiled for hibernating usage as a crashdump kernel
>    with kexec, the same kernel as that of 3 can be used if
>    CONFIG_RELOCATABLE=y is selected. The kernel command line option as
>    following must be appended to kernel command line.
> 
>    kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`
> 
>    For example, the shell command line can be as follow:
> 
>    kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal
>        kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"

I think I followed the instructions closely. Now I'm trying to do 

kexec -p /data/l/linux/vmlinux --args-linux --append="init=/bin/bash
kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"

but it tells me:

Invalid memory segment 0x100000 - 0x7a0fff

(and nothing in dmesg) 

If I try to load bzImage (corresponding to vmlinux I tried to use),  I
get:

root at amd:~# kexec -p /data/l/linux/arch/i386/boot/bzImage --append="init=/bin/bash kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"
Could not find a free area of memory of 9000 bytes...
locate_hole failed
root at amd:~#

What am I doing wrong?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at ucw.cz  Tue Jul 31 07:12:08 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 13:12:08 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <m17iogrgjw.fsf@ebiederm.dsl.xmission.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731091004.GA2022@elf.ucw.cz>
	<1185873924.23149.86.camel@caritas-dev.intel.com>
	<m17iogrgjw.fsf@ebiederm.dsl.xmission.com>
Message-ID: <20070731111208.GA1778@elf.ucw.cz>

Hi!

> >> >  
> >> > +/* Adds the kexec_backup= command line parameter to command line. */
> >> > +static int cmdline_add_backup(char *cmdline, unsigned long addr)
> >> > +{
> >> > +	int cmdlen, len, align = 1024;
> >> > +	char str[30], *ptr;
> >> > +
> >> > +	/* Passing in kexec_backup=xxxK format. Saves space required
> >> > +	 * in cmdline. Ensure 1K alignment*/
> >> > +	if (addr%align)
> >> > +		return -1;
> >> > +	addr = addr/align;
> >> > +	ptr = str;
> >> > +	strcpy(str, " kexec_backup=");
> >> > +	ptr += strlen(str);
> >> > +	ultoa(addr, ptr);
> >> > +	strcat(str, "K");
> >> > +	len = strlen(str);
> >> > +	cmdlen = strlen(cmdline) + len;
> >> > +	if (cmdlen > (COMMAND_LINE_SIZE - 1))
> >> > +		die("Command line overflow\n");
> >> > +	strcat(cmdline, str);
> >> > +	return 0;
> >> > +}
> >> 
> >> This part did not apply for me -- it seems crashdump related and I did
> >> not have that applied. Is it critical?
> >
> > This is needed for kexec_jump to work properly. Which version of
> > kexec-tools do you use? This patch is against 1.101. The kdump patch
> > must be applied before this patch is applied.
> 
> Please work against the kexec-tools-testing tree, if you can.
> All of the outstanding patches should be there.

So
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
is the right tree to use?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at ucw.cz  Tue Jul 31 07:14:35 2007
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 31 Jul 2007 13:14:35 +0200
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1185873924.23149.86.camel@caritas-dev.intel.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731091004.GA2022@elf.ucw.cz>
	<1185873924.23149.86.camel@caritas-dev.intel.com>
Message-ID: <20070731111435.GB1778@elf.ucw.cz>

Hi!

> > This part did not apply for me -- it seems crashdump related and I did
> > not have that applied. Is it critical?
> 
> This is needed for kexec_jump to work properly. Which version of
> kexec-tools do you use? This patch is against 1.101. The kdump patch
> must be applied before this patch is applied.

Ok, did that, got a clean compile, but still could not get it to work.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From ebiederm at xmission.com  Tue Jul 31 06:52:35 2007
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 31 Jul 2007 04:52:35 -0600
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <1185873924.23149.86.camel@caritas-dev.intel.com> (Ying Huang's
	message of "Tue, 31 Jul 2007 17:25:24 +0800")
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731091004.GA2022@elf.ucw.cz>
	<1185873924.23149.86.camel@caritas-dev.intel.com>
Message-ID: <m17iogrgjw.fsf@ebiederm.dsl.xmission.com>

"Huang, Ying" <ying.huang at intel.com> writes:

> On Tue, 2007-07-31 at 11:10 +0200, Pavel Machek wrote:
>> > Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
>> > ===================================================================
>> > --- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c 2007-07-08
> 23:00:25.000000000 +0800
>> > +++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c 2007-07-14
> 17:06:45.000000000 +0800
>> > @@ -428,6 +428,29 @@
>> >  	return 0;
>> >  }
>> >  
>> > +/* Adds the kexec_backup= command line parameter to command line. */
>> > +static int cmdline_add_backup(char *cmdline, unsigned long addr)
>> > +{
>> > +	int cmdlen, len, align = 1024;
>> > +	char str[30], *ptr;
>> > +
>> > +	/* Passing in kexec_backup=xxxK format. Saves space required
>> > +	 * in cmdline. Ensure 1K alignment*/
>> > +	if (addr%align)
>> > +		return -1;
>> > +	addr = addr/align;
>> > +	ptr = str;
>> > +	strcpy(str, " kexec_backup=");
>> > +	ptr += strlen(str);
>> > +	ultoa(addr, ptr);
>> > +	strcat(str, "K");
>> > +	len = strlen(str);
>> > +	cmdlen = strlen(cmdline) + len;
>> > +	if (cmdlen > (COMMAND_LINE_SIZE - 1))
>> > +		die("Command line overflow\n");
>> > +	strcat(cmdline, str);
>> > +	return 0;
>> > +}
>> 
>> This part did not apply for me -- it seems crashdump related and I did
>> not have that applied. Is it critical?
>
> This is needed for kexec_jump to work properly. Which version of
> kexec-tools do you use? This patch is against 1.101. The kdump patch
> must be applied before this patch is applied.

Please work against the kexec-tools-testing tree, if you can.
All of the outstanding patches should be there.

Eric


From ying.huang at intel.com  Tue Jul 31 21:16:13 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Wed, 01 Aug 2007 09:16:13 +0800
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <m17iogrgjw.fsf@ebiederm.dsl.xmission.com>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731091004.GA2022@elf.ucw.cz>
	<1185873924.23149.86.camel@caritas-dev.intel.com>
	<m17iogrgjw.fsf@ebiederm.dsl.xmission.com>
Message-ID: <1185930973.1363.1.camel@caritas-dev.intel.com>

On Tue, 2007-07-31 at 04:52 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <ying.huang at intel.com> writes:
> 
> > On Tue, 2007-07-31 at 11:10 +0200, Pavel Machek wrote:
> >> > Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
> >> > ===================================================================
> >> > --- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c 2007-07-08
> > 23:00:25.000000000 +0800
> >> > +++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c 2007-07-14
> > 17:06:45.000000000 +0800
> >> > @@ -428,6 +428,29 @@
> >> >  	return 0;
> >> >  }
> >> >  
> >> > +/* Adds the kexec_backup= command line parameter to command line. */
> >> > +static int cmdline_add_backup(char *cmdline, unsigned long addr)
> >> > +{
> >> > +	int cmdlen, len, align = 1024;
> >> > +	char str[30], *ptr;
> >> > +
> >> > +	/* Passing in kexec_backup=xxxK format. Saves space required
> >> > +	 * in cmdline. Ensure 1K alignment*/
> >> > +	if (addr%align)
> >> > +		return -1;
> >> > +	addr = addr/align;
> >> > +	ptr = str;
> >> > +	strcpy(str, " kexec_backup=");
> >> > +	ptr += strlen(str);
> >> > +	ultoa(addr, ptr);
> >> > +	strcat(str, "K");
> >> > +	len = strlen(str);
> >> > +	cmdlen = strlen(cmdline) + len;
> >> > +	if (cmdlen > (COMMAND_LINE_SIZE - 1))
> >> > +		die("Command line overflow\n");
> >> > +	strcat(cmdline, str);
> >> > +	return 0;
> >> > +}
> >> 
> >> This part did not apply for me -- it seems crashdump related and I did
> >> not have that applied. Is it critical?
> >
> > This is needed for kexec_jump to work properly. Which version of
> > kexec-tools do you use? This patch is against 1.101. The kdump patch
> > must be applied before this patch is applied.
> 
> Please work against the kexec-tools-testing tree, if you can.
> All of the outstanding patches should be there.

OK, I will work against the kexec-tools-testing tree in the next
version.

Best Regards,
Huang Ying


From ying.huang at intel.com  Tue Jul 31 21:34:31 2007
From: ying.huang at intel.com (Huang, Ying)
Date: Wed, 01 Aug 2007 09:34:31 +0800
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based
	hibernation
In-Reply-To: <20070731110458.GA1777@elf.ucw.cz>
References: <1184483593.1898.98.camel@caritas-dev.intel.com>
	<20070731110458.GA1777@elf.ucw.cz>
Message-ID: <1185932071.1363.13.camel@caritas-dev.intel.com>

On Tue, 2007-07-31 at 13:04 +0200, Pavel Machek wrote:
> Hi!
> 
> > 3. Boot kernel compiled for normal usage, the reserved crash kernel
> >    memory region must be added to kernel command line as following:
> > 
> >    crashkernel=<XX>M@<XX>M
> > 
> >    Where, <XX> should be replaced by the real memory size and
> > position.
> 
> I used crashkernel=64M at 64M .
> 
> 
> > 4. Load kernel compiled for hibernating usage as a crashdump kernel
> >    with kexec, the same kernel as that of 3 can be used if
> >    CONFIG_RELOCATABLE=y is selected. The kernel command line option as
> >    following must be appended to kernel command line.
> > 
> >    kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`
> > 
> >    For example, the shell command line can be as follow:
> > 
> >    kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal
> >        kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"
> 
> I think I followed the instructions closely. Now I'm trying to do 
> 
> kexec -p /data/l/linux/vmlinux --args-linux --append="init=/bin/bash
> kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"
> 
> but it tells me:
> 
> Invalid memory segment 0x100000 - 0x7a0fff
> 
> (and nothing in dmesg) 
> 
> If I try to load bzImage (corresponding to vmlinux I tried to use),  I
> get:
> 
> root at amd:~# kexec -p /data/l/linux/arch/i386/boot/bzImage --append="init=/bin/bash kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"
> Could not find a free area of memory of 9000 bytes...
> locate_hole failed
> root at amd:~#
> 
> What am I doing wrong?

The kexec-tools version 1.101 does not work perfectly with relocatable
kernel. This would have been solved if I worked against kexec-tools
testing tree. I will work against testing tree in the next version.

But, with some trick, it can work. When configure kernel, make sure the
following option is set:

CONFIG_PHYSICAL_START=0x4000000 # if crashkernel=<XX>M at 64M

Best Regards,
Huang Ying


