Re: linux-next: Tree for Dec 1 (riscv, crash_core)
On 12/1/23 18:22, Baoquan He wrote: > On 12/01/23 at 11:53am, Randy Dunlap wrote: >> >> >> On 11/30/23 18:37, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20231130: >>> >> >> on riscv 32-bit or 64-bit, with >> # CONFIG_MMU is not set > > Can you provide your .config so that I reproduce it? Disabling > CONFIG_MMU need find all places where it's selected by other config items. > Sure. This is for riscv 64-bit. -- ~Randy config-r3049.gz Description: application/gzip ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] riscv, crash: don't export some symbols when CONFIG_MMU=n
On 12/4/23 23:18, Baoquan He wrote:
> On 12/04/23 at 11:14am, Randy Dunlap wrote:
[]
>>
>> Both riscv 32-bit and 64-bit complain:
>>
>> ../arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
>> ../arch/riscv/kernel/crash_core.c:11:58: warning: format '%lx' expects
>> argument of type 'long unsigned int', but argument 2 has type 'int'
>> [-Wformat=]
>>11 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>> VMALLOC_START);
>> |~~^
>> | |
>> | long
>> unsigned int
>> |%x
>
> Thanks for all these testing.
>
> This warning is irrelevant to the kexec patch, it's becasue
> VMALLOC_START is defined as 0 which is int when CONFIG_MMU=n.
>
> Below patch can fix the warning.
>
> From 46984a0287e5f1b41ae3e9adfcfa0d26b71db8f4 Mon Sep 17 00:00:00 2001
> From: Baoquan He
> Date: Tue, 5 Dec 2023 11:02:55 +0800
> Subject: [PATCH] riscv: fix VMALLC_START definition
> Content-type: text/plain
>
> When below config items are set, compiler complained:
>
>
> CONFIG_CRASH_CORE=y
> CONFIG_KEXEC_CORE=y
> CONFIG_CRASH_DUMP=y
> ..
> ---
>
> ---
> arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
> arch/riscv/kernel/crash_core.c:11:58: warning: format '%lx' expects argument
> of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=]
> 11 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> VMALLOC_START);
>|~~^
>| |
>| long unsigned
> int
>|%x
> --
>
> This is because on riscv macro VMALLOC_START has different type when
> CONFIG_MMU is set or unset.
>
> arch/riscv/include/asm/pgtable.h:
> --
>
> Changing it to _AC(0, UL) in case CONFIG_MMU=n can fix the warning.
>
> Signed-off-by: Baoquan He
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap # build-tested
Thanks.
> ---
> arch/riscv/include/asm/pgtable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/pgtable.h
> b/arch/riscv/include/asm/pgtable.h
> index 294044429e8e..ab00235b018f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -899,7 +899,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> #define PAGE_KERNEL __pgprot(0)
> #define swapper_pg_dir NULL
> #define TASK_SIZE0xUL
> -#define VMALLOC_START0
> +#define VMALLOC_START_AC(0, UL)
> #define VMALLOC_END TASK_SIZE
>
> #endif /* !CONFIG_MMU */
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: linux-next: Tree for Dec 1 (riscv, crash_core)
Hi, On 12/3/23 18:10, Baoquan He wrote: > eric_devol...@yahoo.com, ig...@cloudflare.com, > Linux Next Mailing List , > Linux Kernel Mailing List , > linux-riscv , > kexec > Bcc: b...@redhat.com > Subject: Re: linux-next: Tree for Dec 1 (riscv, crash_core) > Reply-To: > In-Reply-To: > > On 12/01/23 at 11:53am, Randy Dunlap wrote: >> >> >> On 11/30/23 18:37, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20231130: >>> >> >> on riscv 32-bit or 64-bit, with >> # CONFIG_MMU is not set > [] > I made two patches to decouple the kexec/crash code with CONFIG_MMU. Not > sure if risc-v wants that. > > Or we can simply add dependency on MMU for ARCH_SUPPORTS_CRASH_DUMP. > Then when CONFIG_MMU=n, CONFIG_CRASH_DUMP, CONFIG_KEXEC_CORE, > CONFIG_CRASH_CORE will be unset too. Please help check which one need be > taken. > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 24c1799e2ec4..03d290da7262 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -708,6 +708,7 @@ config ARCH_SUPPORTS_KEXEC_PURGATORY > > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > + depends on MMU=y > > config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION > def_bool CRASH_CORE > That works if the RISC-V folks prefer it. Tested-by: Randy Dunlap # build-tested Thanks. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/2] riscv, kexec: fix dependency of two items
On 12/3/23 18:23, Baoquan He wrote: > Drop the dependency on MMU from ARCH_SUPPORTS_KEXEC and > ARCH_SUPPORTS_KEXEC_FILE because CONFIG_MMU could be disabled while > people may still want to have KEXEC/KEXEC_FILE functionality. > > Signed-off-by: Baoquan He Tested-by: Randy Dunlap # build-tested Thanks. > --- > arch/riscv/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 95a2a06acc6a..24c1799e2ec4 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -685,7 +685,7 @@ config RISCV_BOOT_SPINWAIT > If unsure what to do here, say N. > > config ARCH_SUPPORTS_KEXEC > - def_bool MMU > + def_bool y > > config ARCH_SELECTS_KEXEC > def_bool y > @@ -693,7 +693,7 @@ config ARCH_SELECTS_KEXEC > select HOTPLUG_CPU if SMP > > config ARCH_SUPPORTS_KEXEC_FILE > - def_bool 64BIT && MMU > + def_bool 64BIT > > config ARCH_SELECTS_KEXEC_FILE > def_bool y -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] riscv, crash: don't export some symbols when CONFIG_MMU=n
On 12/3/23 18:19, Baoquan He wrote:
> When dropping select of KEXEC and dependency on ARCH_SUPPORTS_KEXEC
> from CRASH_DUMP, compiling error is reported when below config items are
> set:
> ---
> CONFIG_CRASH_CORE=y
> CONFIG_KEXEC_CORE=y
> CONFIG_CRASH_DUMP=y
> ..
> ---
>
[]
>
> Currently, riscv's ARCH_SUPPORTS_KEXEC has dependency on MMU. Before
> dropping ARCH_SUPPORTS_KEXEC, disabling CONFIG_MMU will unset
> CONFIG_CRASH_DUMP, CONFIG_KEXEC_CORE, CONFIG_CRASH_CORE. Hence
> crash_core related codes won't be compiled.
>
> -
> arch/riscv/Kconfig:
> config ARCH_SUPPORTS_KEXEC
> def_bool MMU
> -
>
> After dropping ARCH_SUPPORTS_KEXEC, CONFIG_CRASH_DUMP, CONFIG_KEXEC_CORE,
> CONFIG_CRASH_CORE can be set independently of CONFIG_MMU. However, there
> are several macro definitions, such as VA_BITS, VMEMMAP_START, VMEMMAP_END,
> MODULES_VADDR, MODULES_END are only available when CONFIG_MMU=y. Then
> compiling errors are triggered.
>
> Here, add CONFIG_MMU ifdeffery in arch_crash_save_vmcoreinfo() to export
> those symbols when CONFIG_MMU is enabled.
>
> Signed-off-by: Baoquan He
> ---
> arch/riscv/kernel/crash_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> index 55f1d7856b54..8706736fd4e2 100644
> --- a/arch/riscv/kernel/crash_core.c
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -5,17 +5,19 @@
>
> void arch_crash_save_vmcoreinfo(void)
> {
> - VMCOREINFO_NUMBER(VA_BITS);
> VMCOREINFO_NUMBER(phys_ram_base);
>
> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +#ifdef CONFIG_MMU
> + VMCOREINFO_NUMBER(VA_BITS);
> vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> #ifdef CONFIG_64BIT
> vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> #endif
> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> KERNEL_LINK_ADDR);
> vmcoreinfo_append_str("NUMBER(va_kernel_pa_offset)=0x%lx\n",
Both riscv 32-bit and 64-bit complain:
../arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
../arch/riscv/kernel/crash_core.c:11:58: warning: format '%lx' expects argument
of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=]
11 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
VMALLOC_START);
| ~~^
| |
| long unsigned
int
|%x
Otherwise this builds without failure.
Tested-by: Randy Dunlap # build-tested
Thanks.
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: linux-next: Tree for Dec 1 (riscv, crash_core)
On 11/30/23 18:37, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20231130:
>
on riscv 32-bit or 64-bit, with
# CONFIG_MMU is not set
In file included from ../arch/riscv/kernel/crash_core.c:3:
../arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
../arch/riscv/kernel/crash_core.c:8:27: error: 'VA_BITS' undeclared (first use
in this function)
8 | VMCOREINFO_NUMBER(VA_BITS);
| ^~~
../include/linux/crash_core.h:78:64: note: in definition of macro
'VMCOREINFO_NUMBER'
78 | vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
|^~~~
../arch/riscv/kernel/crash_core.c:8:27: note: each undeclared identifier is
reported only once for each function it appears in
8 | VMCOREINFO_NUMBER(VA_BITS);
| ^~~
../include/linux/crash_core.h:78:64: note: in definition of macro
'VMCOREINFO_NUMBER'
78 | vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
|^~~~
../arch/riscv/kernel/crash_core.c:12:58: warning: format '%lx' expects argument
of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=]
12 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
VMALLOC_START);
|~~^
| |
| long unsigned
int
|%x
../arch/riscv/kernel/crash_core.c:14:64: error: 'VMEMMAP_START' undeclared
(first use in this function)
14 | vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
VMEMMAP_START);
|
^
../arch/riscv/kernel/crash_core.c:15:62: error: 'VMEMMAP_END' undeclared (first
use in this function); did you mean 'MEMREMAP_ENC'?
15 | vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
VMEMMAP_END);
| ^~~
|
MEMREMAP_ENC
64-bit only:
../arch/riscv/kernel/crash_core.c:17:64: error: 'MODULES_VADDR' undeclared
(first use in this function)
17 | vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
MODULES_VADDR);
|
^
../arch/riscv/kernel/crash_core.c:18:62: error: 'MODULES_END' undeclared (first
use in this function)
18 | vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
MODULES_END);
| ^~~
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v25 06/10] crash: memory and CPU hotplug sysfs attributes
On 6/29/23 15:31, Eric DeVolder wrote: >> Did you test build the documentation? >> It looks to me like the end-of-table '=' signs line needs 3 more === to be >> long >> enough for the text above it. > > Hmm, the 'make htmldocs' renders and views ok. Is there perhaps another > method I should use? No, that's it. Sorry about the noise. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v25 06/10] crash: memory and CPU hotplug sysfs attributes
Hi--
On 6/29/23 12:21, Eric DeVolder wrote:
>
> Signed-off-by: Eric DeVolder
> Reviewed-by: Sourabh Jain
> Acked-by: Hari Bathini
> Acked-by: Baoquan He
> ---
> Documentation/ABI/testing/sysfs-devices-memory | 8
> .../ABI/testing/sysfs-devices-system-cpu | 8
> .../admin-guide/mm/memory-hotplug.rst | 8
> Documentation/core-api/cpu_hotplug.rst | 18 ++
> drivers/base/cpu.c | 16 ++--
> drivers/base/memory.c | 13 +
> include/linux/kexec.h | 8
> 7 files changed, 77 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst
> b/Documentation/admin-guide/mm/memory-hotplug.rst
> index 1b02fe5807cc..eb99d79223a3 100644
> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> @@ -291,6 +291,14 @@ The following files are currently defined:
> Availability depends on the CONFIG_ARCH_MEMORY_PROBE
> kernel configuration option.
> ``uevent`` read-write: generic udev file for device subsystems.
> +``crash_hotplug`` read-only: when changes to the system memory map
> +occur due to hot un/plug of memory, this file contains
> +'1' if the kernel updates the kdump capture kernel memory
> +map itself (via elfcorehdr), or '0' if userspace must
> update
> +the kdump capture kernel memory map.
> +
> +Availability depends on the CONFIG_MEMORY_HOTPLUG kernel
> +configuration option.
> ==
> =
Did you test build the documentation?
It looks to me like the end-of-table '=' signs line needs 3 more === to be long
enough for the text above it.
>
> .. note::
> diff --git a/Documentation/core-api/cpu_hotplug.rst
> b/Documentation/core-api/cpu_hotplug.rst
> index e6f5bc39cf5c..54581c501562 100644
> --- a/Documentation/core-api/cpu_hotplug.rst
> +++ b/Documentation/core-api/cpu_hotplug.rst
> @@ -741,6 +741,24 @@ will receive all events. A script like::
>
> can process the event further.
>
> +When changes to the CPUs in the system occur, the sysfs file
> +/sys/devices/system/cpu/crash_hotplug contains '1' if the kernel
> +updates the kdump capture kernel list of CPUs itself (via elfcorehdr),
> +or '0' if userspace must update the kdump capture kernel list of CPUs.
> +
> +The availability depends on the CONFIG_HOTPLUG_CPU kernel configuration
> +option.
> +
> +To skip userspace processing of CPU hot un/plug events for kdump
> +(ie the unload-then-reload to obtain a current list of CPUs), this sysfs
i.e.
> +file can be used in a udev rule as follows:
> +
> + SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
> +
> +For a cpu hot un/plug event, if the architecture supports kernel updates
CPU
for consistency
> +of the elfcorehdr (which contains the list of CPUs), then the rule skips
> +the unload-then-reload of the kdump capture kernel.
> +
> Kernel Inline Documentations Reference
> ==
>
Thanks.
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: linux-next: Tree for Aug 25 (kunit: virt/nitro_enclaves; also kexec)
On 8/24/22 22:44, Stephen Rothwell wrote: > Hi all, > > Changes since 20220824: > on x86_64: ld: vmlinux.o: in function `kunit_kcalloc': include/kunit/test.h:369: undefined reference to `kunit_kmalloc_array' ld: vmlinux.o: in function `ne_misc_dev_test_merge_phys_contig_memory_regions': drivers/virt/nitro_enclaves/ne_misc_dev_test.c:120: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:141: undefined reference to `kunit_kfree' ld: vmlinux.o: in function `kexec_purgatory_size': (.rodata+0x209ee0): undefined reference to `kunit_unary_assert_format' Full randconfig file is attached. -- ~Randy config-r5934.gz Description: application/gzip ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] docs: Fix typo in comment
On 7/25/22 06:57, William Breathitt Gray wrote:
> On Mon, Jul 25, 2022 at 06:52:15AM -0700, Joe Perches wrote:
>> On Fri, 2022-07-22 at 07:45 +0800, Baoquan He wrote:
>>> On 07/21/22 at 11:40am, Randy Dunlap wrote:
>>>> On 7/21/22 11:36, Jonathan Corbet wrote:
>>>>> "Slark Xiao" writes:
>>>>>> May I know the maintainer of one subsystem could merge the changes
>>>>>> contains lots of subsystem? I also know this could be filtered by
>>>>>> grep and sed command, but that patch would have dozens of maintainers
>>>>>> and reviewers.
>>>>>
>>>>> Certainly I don't think I can merge a patch touching 166 files across
>>>>> the tree. This will need to be broken down by subsystem, and you may
>>>>> well find that there are some maintainers who don't want to deal with
>>>>> this type of minor fix.
>>>>
>>>> We have also seen cases where "the the" should be replaced by "then the"
>>>> or some other pair of words, so some of these changes could fall into
>>>> that category.
>>>
>>> It's possible. I searched in Documentation and went through each place,
>>> seems no typo of "then the". Below patch should clean up all the 'the the'
>>> typo under Documentation.
>> []
>>> The fix is done with below command:
>>> sed -i "s/the the /the /g" `git grep -l "the the " Documentation`
>>
>> This command misses entries at EOL:
>>
>> Documentation/trace/histogram.rst: Here's an example where we use a
>> compound key composed of the the
>>
>> Perhaps a better conversion would be 's/\bthe the\b/the/g'
>
> It would be good to check for instances that cross newlines as well;
> i.e. "the" at the end of a line followed by "the" at the start of the
> next line. However, this would require some thought to properly account
> for comment blocks ("*") and other similar prefixes that should be
> ignored.
Yeah, the script that I posted last year (?) does that, but it's noisy --
results need to be hand-checked.
It's not clear how people are finding these repeated words, other than
something like
$ grep "the the" *
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] docs: Fix typo in comment
On 7/21/22 11:36, Jonathan Corbet wrote: > "Slark Xiao" writes: > >> May I know the maintainer of one subsystem could merge the changes >> contains lots of subsystem? I also know this could be filtered by >> grep and sed command, but that patch would have dozens of maintainers >> and reviewers. > > Certainly I don't think I can merge a patch touching 166 files across > the tree. This will need to be broken down by subsystem, and you may > well find that there are some maintainers who don't want to deal with > this type of minor fix. We have also seen cases where "the the" should be replaced by "then the" or some other pair of words, so some of these changes could fall into that category. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: linux-next: Tree for May 31 (riscv: arch/riscv/kernel/elf_kexec.c)
838b3e28488f7: RISC-V: Load purgatory in kexec_file
On 5/30/22 21:54, Stephen Rothwell wrote:
> Hi all,
>
> Note: please do not add any v5.20 material to your linux-next included
> branches until after v5.19-rc1 has been related.
>
> Changes since 20220527:
>
When CONFIG_MODULES is not set/enabled:
(oh, also CONFIG_MMU is not set)
../arch/riscv/kernel/elf_kexec.c:346:5: error: redefinition of
'arch_kexec_apply_relocations_add'
346 | int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
| ^~~~
In file included from ../arch/riscv/kernel/elf_kexec.c:17:
../include/linux/kexec.h:236:1: note: previous definition of
'arch_kexec_apply_relocations_add' with type 'int(struct purgatory_info *,
Elf64_Shdr *, const Elf64_Shdr *, const Elf64_Shdr *)' {aka 'int(struct
purgatory_info *, struct elf64_shdr *, const struct elf64_shdr *, const struct
elf64_shdr *)'}
236 | arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr
*section,
| ^~~~
../arch/riscv/kernel/elf_kexec.c: In function
'arch_kexec_apply_relocations_add':
../arch/riscv/kernel/elf_kexec.c:353:9: error: unknown type name 'Elf_Rela';
did you mean 'Elf64_Rela'?
353 | Elf_Rela *relas;
| ^~~~
| Elf64_Rela
In file included from ../arch/riscv/include/asm/elf.h:11,
from ../include/linux/elf.h:6,
from ../include/linux/module.h:19,
from ../arch/riscv/kernel/elf_kexec.c:15:
../arch/riscv/kernel/elf_kexec.c:371:44: error: request for member 'r_info' in
something not a structure or union
371 | sym += ELF64_R_SYM(relas[i].r_info);
|^
../include/uapi/linux/elf.h:163:43: note: in definition of macro 'ELF64_R_SYM'
163 | #define ELF64_R_SYM(i) ((i) >> 32)
| ^
../arch/riscv/kernel/elf_kexec.c:380:32: error: request for member 'r_offset'
in something not a structure or union
380 | loc += relas[i].r_offset;
|^
../arch/riscv/kernel/elf_kexec.c:393:32: error: request for member 'r_addend'
in something not a structure or union
393 | val += relas[i].r_addend;
|^
../arch/riscv/kernel/elf_kexec.c:395:51: error: request for member 'r_offset'
in something not a structure or union
395 | addr = section->sh_addr + relas[i].r_offset;
| ^
In file included from ../arch/riscv/include/asm/elf.h:11,
from ../include/linux/elf.h:6,
from ../include/linux/module.h:19,
from ../arch/riscv/kernel/elf_kexec.c:15:
../arch/riscv/kernel/elf_kexec.c:397:47: error: request for member 'r_info' in
something not a structure or union
397 | r_type = ELF64_R_TYPE(relas[i].r_info);
| ^
../include/uapi/linux/elf.h:164:43: note: in definition of macro 'ELF64_R_TYPE'
164 | #define ELF64_R_TYPE(i) ((i) & 0x)
| ^
Full randconfig file is attached.
--
~Randy
config-r3359.gz
Description: application/gzip
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISCV: kexec: Fix build error without CONFIG_MODULES
Hi--
On 5/31/22 23:39, Li Zhengyu wrote:
> When CONFIG_MODULES is not set/enabled:
>
> ../arch/riscv/kernel/elf_kexec.c:353:9: error: unknown type name 'Elf_Rela';
> did you mean 'Elf64_Rela'?
> 353 | Elf_Rela *relas;
> | ^~~~
> | Elf64_Rela
>
> Replace Elf_Rela by Elf64_Rela to avoid relying on CONFIG_MODULES.
>
BTW, does this mean that RISC-V kexec is only available on 64BIT
and not on 32BIT?
thanks.
> Signed-off-by: Li Zhengyu
> ---
> arch/riscv/kernel/elf_kexec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> index 9cb85095fd45..0cb94992c15b 100644
> --- a/arch/riscv/kernel/elf_kexec.c
> +++ b/arch/riscv/kernel/elf_kexec.c
> @@ -349,7 +349,7 @@ int arch_kexec_apply_relocations_add(struct
> purgatory_info *pi,
> {
> const char *strtab, *name, *shstrtab;
> const Elf_Shdr *sechdrs;
> - Elf_Rela *relas;
> + Elf64_Rela *relas;
> int i, r_type;
>
> /* String & section header string table */
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISCV: kexec: Fix build error without CONFIG_MODULES
On 5/31/22 23:39, Li Zhengyu wrote:
> When CONFIG_MODULES is not set/enabled:
>
> ../arch/riscv/kernel/elf_kexec.c:353:9: error: unknown type name 'Elf_Rela';
> did you mean 'Elf64_Rela'?
> 353 | Elf_Rela *relas;
> | ^~~~
> | Elf64_Rela
>
> Replace Elf_Rela by Elf64_Rela to avoid relying on CONFIG_MODULES.
>
> Signed-off-by: Li Zhengyu
Reported-by: Randy Dunlap
Tested-by: Randy Dunlap
Acked-by: Randy Dunlap
thanks.
> ---
> arch/riscv/kernel/elf_kexec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> index 9cb85095fd45..0cb94992c15b 100644
> --- a/arch/riscv/kernel/elf_kexec.c
> +++ b/arch/riscv/kernel/elf_kexec.c
> @@ -349,7 +349,7 @@ int arch_kexec_apply_relocations_add(struct
> purgatory_info *pi,
> {
> const char *strtab, *name, *shstrtab;
> const Elf_Shdr *sechdrs;
> - Elf_Rela *relas;
> + Elf64_Rela *relas;
> int i, r_type;
>
> /* String & section header string table */
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISC-V: kexec: Fix build error without CONFIG_KEXEC
On 6/1/22 00:02, Li Zhengyu wrote: > When CONFIG_KEXEC_FILE=y but CONFIG_KEXEC is not set: > > kernel/kexec_core.o: In function `kimage_free': > kexec_core.c:(.text+0xa0c): undefined reference to `machine_kexec_cleanup' > kernel/kexec_core.o: In function `.L0 ': > kexec_core.c:(.text+0xde8): undefined reference to `machine_crash_shutdown' > kexec_core.c:(.text+0xdf4): undefined reference to `machine_kexec' > kernel/kexec_core.o: In function `.L231': > kexec_core.c:(.text+0xe1c): undefined reference to `riscv_crash_save_regs' > kernel/kexec_core.o: In function `.L0 ': > kexec_core.c:(.text+0x119e): undefined reference to `machine_shutdown' > kernel/kexec_core.o: In function `.L312': > kexec_core.c:(.text+0x11b2): undefined reference to `machine_kexec' > kernel/kexec_file.o: In function `.L0 ': > kexec_file.c:(.text+0xb84): undefined reference to `machine_kexec_prepare' > kernel/kexec_file.o: In function `.L177': > kexec_file.c:(.text+0xc5a): undefined reference to `machine_kexec_prepare' > Makefile:1160: recipe for target 'vmlinux' failed > make: *** [vmlinux] Error 1 > > These symbols should depend on CONFIG_KEXEC_CORE rather than CONFIG_KEXEC > when kexec_file has been implemented on RISC-V, like the other archs have > done. > > Signed-off-by: Li Zhengyu Reported-by: Randy Dunlap Tested-by: Randy Dunlap Acked-by: Randy Dunlap thanks. > --- > arch/riscv/kernel/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index c71d6591d539..33bb60a354cd 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -78,7 +78,7 @@ obj-$(CONFIG_SMP) += cpu_ops_sbi.o > endif > obj-$(CONFIG_HOTPLUG_CPU)+= cpu-hotplug.o > obj-$(CONFIG_KGDB) += kgdb.o > -obj-$(CONFIG_KEXEC) += kexec_relocate.o crash_save_regs.o > machine_kexec.o > +obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o > machine_kexec.o > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 24/30] panic: Refactor the panic path
On 4/27/22 15:49, Guilherme G. Piccoli wrote: > + crash_kexec_post_notifiers > + This was DEPRECATED - users should always prefer the This is DEPRECATED - users should always prefer the > + parameter "panic_notifiers_level" - check its entry > + in this documentation for details on how it works. > + Setting this parameter is exactly the same as setting > + "panic_notifiers_level=4". -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC v2 01/43] mm: add PKRAM API stubs and Kconfig
On 3/30/21 2:35 PM, Anthony Yznaga wrote: > Preserved-across-kexec memory or PKRAM is a method for saving memory > pages of the currently executing kernel and restoring them after kexec > boot into a new one. This can be utilized for preserving guest VM state, > large in-memory databases, process memory, etc. across reboot. While > DRAM-as-PMEM or actual persistent memory could be used to accomplish > these things, PKRAM provides the latency of DRAM with the flexibility > of dynamically determining the amount of memory to preserve. > ... > > Originally-by: Vladimir Davydov > Signed-off-by: Anthony Yznaga > --- > include/linux/pkram.h | 47 + > mm/Kconfig| 9 +++ > mm/Makefile | 1 + > mm/pkram.c| 179 > ++ > 4 files changed, 236 insertions(+) > create mode 100644 include/linux/pkram.h > create mode 100644 mm/pkram.c > > diff --git a/mm/pkram.c b/mm/pkram.c > new file mode 100644 > index ..59e4661b2fb7 > --- /dev/null > +++ b/mm/pkram.c > @@ -0,0 +1,179 @@ > +// SPDX-License-Identifier: GPL-2.0 > +#include > +#include > +#include > +#include > +#include > +#include > + Hi, There are several doc blocks that begin with "/**" but that are not in kernel-doc format (/** means kernel-doc format when inside the kernel source tree). Please either change those to "/*" or convert them to kernel-doc format. The latter is preferable for exported interfaces. > +/** > + * Create a preserved memory node with name @name and initialize stream @ps > + * for saving data to it. > + * > + * @gfp_mask specifies the memory allocation mask to be used when saving > data. > + * > + * Returns 0 on success, -errno on failure. > + * > + * After the save has finished, pkram_finish_save() (or pkram_discard_save() > in > + * case of failure) is to be called. > + */ b) from patch 00/43: documentation/core-api/xarray.rst |8 + How did "documentation" become lower case (instead of Documentation)? thanks. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 11/11] kdump: update Documentation about crashkernel
Hi-- On 1/29/21 11:10 PM, Chen Zhou wrote: > --- > Documentation/admin-guide/kdump/kdump.rst | 22 --- > .../admin-guide/kernel-parameters.txt | 11 -- > 2 files changed, 28 insertions(+), 5 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index a10b545c2070..908e5c8b61ba 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt All of the "arm64" instances in [square brackets] should be "ARM64". > @@ -738,6 +738,9 @@ > [KNL, X86-64] Select a region under 4G first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. > + [KNL, arm64] Try low allocation in DMA zone and fall > back here > + to high allocation if it fails when '@offset' hasn't > been > + specified. > See Documentation/admin-guide/kdump/kdump.rst for > further details. > > crashkernel=range1:size1[,range2:size2,...][@offset] > @@ -754,6 +757,8 @@ > Otherwise memory region will be allocated below 4G, if > available. > It will be ignored if crashkernel=X is specified. > + [KNL, arm64] range in high memory. here > + Allow kernel to allocate physical memory region from > top. > crashkernel=size[KMG],low > [KNL, X86-64] range under 4G. When crashkernel=X,high > is passed, kernel could allocate physical memory region > @@ -762,13 +767,15 @@ > requires at least 64M+32K low memory, also enough extra > low memory is needed to make sure DMA buffers for 32-bit > devices won't run out. Kernel would try to allocate at > - at least 256M below 4G automatically. > + least 256M below 4G automatically. > This one let user to specify own low range under 4G > for second kernel instead. > 0: to disable low allocation. > It will be ignored when crashkernel=X,high is not used > or memory reserved is below 4G. > - > + [KNL, arm64] range in low memory. here > + This one let user to specify a low range in DMA zone for > + crash dump kernel. Thanks. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM
Hi,
On 11/18/20 3:24 PM, Saeed Mirzamohammadi wrote:
> This adds crashkernel=auto feature to configure reserved memory for
> vmcore creation to both x86 and ARM platforms based on the total memory
> size.
>
> Cc: sta...@vger.kernel.org
why?
> Signed-off-by: John Donnelly
> Signed-off-by: Saeed Mirzamohammadi
> ---
> Documentation/admin-guide/kdump/kdump.rst | 5 +
> arch/arm64/Kconfig| 26 ++-
> arch/arm64/configs/defconfig | 1 +
> arch/x86/Kconfig | 26 ++-
> arch/x86/configs/x86_64_defconfig | 1 +
> kernel/crash_core.c | 20 +++--
> 6 files changed, 75 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1515f6f153a0..d359dcffa80e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1135,6 +1135,30 @@ config CRASH_DUMP
>
> For more details see Documentation/admin-guide/kdump/kdump.rst
>
> +if CRASH_DUMP
> +
> +config CRASH_AUTO_STR
> +string "Memory reserved for crash kernel"
use tab instead of spaces above.
> + depends on CRASH_DUMP
> +default "1G-64G:128M,64G-1T:256M,1T-:512M"
ditto.
> + help
> + This configures the reserved memory dependent
> + on the value of System RAM. The syntax is:
> + crashkernel=:[,:,...][@offset]
> + range=start-[end]
> +
> + For example:
> + crashkernel=512M-2G:64M,2G-:128M
> +
> + This would mean:
> +
> + 1) if the RAM is smaller than 512M, then don't reserve anything
> + (this is the "rescue" case)
> + 2) if the RAM size is between 512M and 2G (exclusive), then
> reserve 64M
> + 3) if the RAM size is larger than 2G, then reserve 128M
> +
> +endif # CRASH_DUMP
> +
> config XEN_DOM0
> def_bool y
> depends on XEN
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f6946b81f74a..bacd17312bb1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2049,6 +2049,30 @@ config CRASH_DUMP
> (CONFIG_RELOCATABLE=y).
> For more details see Documentation/admin-guide/kdump/kdump.rst
>
> +if CRASH_DUMP
> +
> +config CRASH_AUTO_STR
> +string "Memory reserved for crash kernel" if X86_64
ditto.
> + depends on CRASH_DUMP
> +default "1G-64G:128M,64G-1T:256M,1T-:512M"
ditto.
> + help
> + This configures the reserved memory dependent
> + on the value of System RAM. The syntax is:
> + crashkernel=:[,:,...][@offset]
> + range=start-[end]
> +
> + For example:
> + crashkernel=512M-2G:64M,2G-:128M
> +
> + This would mean:
> +
> + 1) if the RAM is smaller than 512M, then don't reserve anything
> + (this is the "rescue" case)
> + 2) if the RAM size is between 512M and 2G (exclusive), then
> reserve 64M
> + 3) if the RAM size is larger than 2G, then reserve 128M
> +
> +endif # CRASH_DUMP
> +
> config KEXEC_JUMP
> bool "kexec jump"
> depends on KEXEC && HIBERNATION
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 106e4500fd53..a44cd9cc12c4 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -41,6 +42,15 @@ static int __init parse_crashkernel_mem(char *cmdline,
> unsigned long long *crash_base)
> {
> char *cur = cmdline, *tmp;
> + unsigned long long total_mem = system_ram;
> +
> + /*
> + * Firmware sometimes reserves some memory regions for it's own use.
its
> + * so we get less than actual system memory size.
> + * Workaround this by round up the total size to 128M which is
> + * enough for most test cases.
> + */
> + total_mem = roundup(total_mem, SZ_128M);
thanks.
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
On 8/10/20 9:40 PM, Orson Zhai wrote:
> +/*
> + * struct timestanps - Simultaneous mono/boot/real timestamps
typo:timestamps
> + * @mono:Monotonic timestamp
> + * @boot:Boottime timestamp
> + * @real:Realtime timestamp
> + */
> +struct timestamps {
> + u64 mono;
> + u64 boot;
> + u64 real;
> +};
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3] kernel: add panic_on_taint
On 5/9/20 7:59 PM, Baoquan He wrote: > Read admin-guide/tainted-kernels.rst, but still do not get what 'G' means. I interpret 'G' as GPL (strictly it means that no proprietary module has been loaded). But I don't see why TAINT_PROPRIETARY_MODULE is the only taint flag that has a non-blank c_false character. It could just be blank also AFAICT. Then the 'G' would not be there to confuse us. :) -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC 34/43] shmem: PKRAM: multithread preserving and restoring shmem pages
On 5/6/20 5:42 PM, Anthony Yznaga wrote: > Improve performance by multithreading the work to preserve and restore > shmem pages. > > Add 'pkram_max_threads=' kernel option to specify the maximum number > of threads to use to preserve or restore the pages of a shmem file. > The default is 16. Hi, Please document kernel boot options in Documentation/admin-guide/kernel-parameters.txt. > When preserving pages each thread saves chunks of a file to a pkram_obj > until no more no more chunks are available. > > When restoring pages each thread loads pages using a copy of a > pkram_stream initialized by pkram_prepare_load_obj(). Under the hood > each thread ends up fetching and operating on pkram_link pages. > > Signed-off-by: Anthony Yznaga > --- > include/linux/pkram.h | 2 + > mm/shmem_pkram.c | 101 > +- > 2 files changed, 101 insertions(+), 2 deletions(-) thanks. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kernel: add panic_on_taint
On 5/6/20 3:28 PM, Rafael Aquini wrote: > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 7bc83f3d9bdf..75c02c1841b2 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3404,6 +3404,9 @@ > panic_on_warn panic() instead of WARN(). Useful to cause kdump > on a WARN(). > > + panic_on_taint panic() when the kernel gets tainted, if the taint > + flag being set matches with the assigned bitmask. > + Where is the bitmask assigned? I.e., maybe this text should be more like: panic_on_taint= and then the bits are explained. See e.g. panic= and panic_print= in this same file. > crash_kexec_post_notifiers > Run kdump after running panic-notifiers and dumping > kmsg. This only for the users who doubt kdump always -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
Hi,
Just fix a few of the commit log comments...
On 1/13/19 7:15 PM, Pingfan Liu wrote:
> People reported a bug on a high end server with many pcie devices, where
> kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> though we still see much memory under 896 MB, the finding still failed
> intermittently. Because currently we can only find region under 896 MB,
> if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
if w/o
or preferably:
if without
> randomly, and crashkernel reservation need be aligned to 128 MB, that's
> why failure is found. It raises confusion to the end user that sometimes
> crashkernel=X works while sometimes fails.
> If want to make it succeed, customer can change kernel option to
> "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
no space? just
"crashkernel=384M,high"
> limited space to behave even though its grammer looks more generic.
grammar
> And we can't answer questions raised from customer that confidently:
> 1) why it doesn't succeed to reserve 896 MB;
> 2) what's wrong with memory region under 4G;
> 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
> finally above 4G.
> Dave Young sent the original post, and I just re-post it with commit log
> improvement as his requirement.
> http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> There was an old discussion below (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601
>
> Signed-off-by: Pingfan Liu
> Cc: Dave Young
> Cc: Baoquan He
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: ying...@kernel.org,
> Cc: vgo...@redhat.com
> ---
> v5 -> v6
> discard bottom-up allocation, just repost dyoung's original patch with
> commit log improved
> ---
> arch/x86/kernel/setup.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 3d872a5..fa62c81 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -551,6 +551,22 @@ static void __init reserve_crashkernel(void)
> high ? CRASH_ADDR_HIGH_MAX
>: CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> + /*
> + * crashkernel=X reserve below 896M fails? Try below 4G
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + (1ULL << 32),
> + crash_size, CRASH_ALIGN);
> + /*
> + * crashkernel=X reserve below 4G fails? Try MAXMEM
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
> +#endif
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable
> area found.\n");
> return;
>
ciao.
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: linux-next: Tree for Mar 20 (vmcore)
On 03/20/13 11:56, David Rientjes wrote: On Wed, 20 Mar 2013, Randy Dunlap wrote: on x86_64: fs/proc/vmcore.c: In function 'merge_note_headers_elf64': fs/proc/vmcore.c:349:22: error: 'VMCOREINFO_NOTE_NAME' undeclared (first use in this function) fs/proc/vmcore.c:349:22: note: each undeclared identifier is reported only once for each function it appears in fs/proc/vmcore.c: In function 'merge_note_headers_elf32': fs/proc/vmcore.c:470:22: error: 'VMCOREINFO_NOTE_NAME' undeclared (first use in this function) make[3]: *** [fs/proc/vmcore.o] Error 1 Needs to #include linux/kexec.h I don't think that's it, linux/kexec.h already gets included indirectly. The problem is that CONFIG_KEXEC isn't set so the definition in kexec.h is meaningless. Thanks. I meant to check on CONFIG_KEXEC and then forgot to do that. This comes from vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer merged through the -mm tree. I've added the patch's author and Andrew to the cc. How can this be protected by CONFIG_KEXEC? -- -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 -next] Documentation: Improve crashkernel= description
On Mon, 7 Feb 2011 18:01:27 +0200 Ahmed S. Darwish wrote: On Mon, Feb 07, 2011 at 09:25:50AM -0500, Vivek Goyal wrote: On Mon, Feb 07, 2011 at 01:30:54PM +0200, Ahmed S. Darwish wrote: Had to explore two C code files to make sense of the 'crashkernel=' kernel parameter values. Improve the situation. Did you look at Documentation/kdump/kdump.txt before looking into the code. I thought kdump.txt explained the meaning of crashkernel= well. In case if it was not obivious that for further details look into kdump.txt, I will suggest to add a line asking reader to look into kdump.txt for more details. Yes, I jumped to the code first :-) Here's a new patch with the link: (Also applicable over latest -rc3) == Complete the crashkernel= kernel parameter documentation. Signed-off-by: Ahmed S. Darwish darwish...@gmail.com --- diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 89835a4..050b0e5 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -545,16 +545,20 @@ and is between 256 and 4096 characters. It is defined in the file Format: first_slot,last_slot,port,enum_bit[,debug] - crashkernel=nn[KMG]@ss[KMG] - [KNL] Reserve a chunk of physical memory to - hold a kernel to switch to with kexec on panic. + crashkernel=size[KMG][@offset[KMG]] + [KNL] Using kexec, Linux can switch to a 'crash kernel' + upon panic. This parameter reserves the physical + memory region [offset, offset + size] for that kernel + image. If '@offset' is omitted, then a suitable offset + is selected automatically. Check + Documentation/kdump/kdump.txt for further details. crashkernel=range1:size1[,range2:size2,...][@offset] [KNL] Same as above, but depends on the memory in the running system. The syntax of range is start-[end] where start and end are both a memory unit (amount[KMG]). See also - Documentation/kdump/kdump.txt for a example. + Documentation/kdump/kdump.txt for an example. cs89x0_dma= [HW,NET] Format: dma Acked-by: Vivek Goyal vgo...@redhat.com Applied v3, along with your KMG info patch. Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: In place kexec
On Thu, 29 Jul 2010 12:51:09 -0700 Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Jul 29, 2010 at 11:29:12AM -0700, H. Peter Anvin wrote: On 07/29/2010 11:06 AM, Eric W. Biederman wrote: Thinking about this I am a bit surprised that you would find DMA left on from a disk driver. Historically disks have been pretty good about shutting off in this scenario. Added to that typically we unmount all filesystems. Calling rmmod on the driver before the final kexec --exec could be interesting, and drivers much more reliably implement .remove than .shutdown. Network drivers are more likely to be a problem, but we should be downing all of the network interfaces before something happens. All of which is to say kexec-in-place has generally been a lot less hassle, because it is so similar to the normal case. In particular, the supposed corruption comes from the firmware logging feature in the qla2xxx driver. I'd really like to understand if this is a kexec problem or a qla2xxx problem. kernel_kexec() kernel_restart_prepare() device_shutdown() I would suspect it to be a qla2xxx driver problem that it did not shut down the device properly. And device_shutdown calls every drivers .shutdown method. Things like this are always a driver problem. so is there a default .shutdown method for drivers that do not specify one? like the qla2xxx driver does not. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
boot hang: async vs. kexec
I (try to) do daily build/boot testing. The newly built kernel is booted via kexec. This was working until sometime between 2.6.28 and 2.6.29-rc1, so I bisected it.* git bisect blames this commit: 96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634 is first bad commit commit 96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634 Author: Dave Kleikamp sha...@linux.vnet.ibm.com Date: Thu Jan 8 09:46:31 2009 -0600 async: Don't call async_synchronize_full_special() while holding sb_lock sync_filesystems() shouldn't be calling async_synchronize_full_special while holding a spinlock. The second while loop in that function is the right place for this anyway. The new/kexec-loaded kernel hangs during initcalls. The last one that I can see (via netconsole, might miss a few of the very last lines) is: calling net_ns_init+0x0/0x14d @ 1 net_namespace: 1008 bytes initcall net_ns_init+0x0/0x14d returned 0 after 0 usecs Any ideas/suggestions? Thanks. *caveat: This was all done with the don't use gcc 4.1.[01] because it miscompiles __weak patch reverted. Could that be an issue/problem here? (I'm using gcc 4.1.1.) -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: newbie question: kexec linux-based bootstrap
Bizhan Gholikhamseh (bgholikh) wrote: I use kexec daily for boot-testing new kernels. I have enabled the kexec in the kernel configuration, when I ran the kexec I get the following error: You enabled kexec in the new kernel that you are trying to load or in the first/running kernel? It appears that kexec is not loaded in the first/running kernel, but it must be enabled for kexec-tools to work correctly. # ./kexec -l ./bzImage kexec_load failed: Function not implemented entry = 0x977b8 flags = 0 nr_segments = 3 segment[0].buf = 0x8071600 segment[0].bufsz = 2a00 segment[0].mem = 0x3000 segment[0].memsz = 3000 segment[1].buf = 0x806a550 segment[1].bufsz = 7060 segment[1].mem = 0x97000 segment[1].memsz = 9000 segment[2].buf = 0xb7c3aa08 segment[2].bufsz = 1d7eb8 segment[2].mem = 0x10 segment[2].memsz = 1d8000 ??? -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: newbie question: kexec linux-based bootstrap
Bizhan Gholikhamseh (bgholikh) wrote: You enabled kexec in the new kernel that you are trying to load or in the first/running kernel? It appears that kexec is not loaded in the first/running kernel, but it must be enabled for kexec-tools to work correctly. Yes, that was the problem, now I am getting a new error, I do not care for crash dump, but when I execute kexec -e it ask me to reserve some space for it and use kdump kernel, which is not the case I am interested: # ./kexec -e -append=root/dev/sdb2 Memory for crashkernel is not reserved Please reserve memory by passing crashkerne...@y parameter to the kernel Then try loading kdump kernel ??? You still need to reserve space for the new kernel to be loaded into. It has to be loaded into memory before it is needed. Those messages that say crashkernel can be misleading, but that's what the kernel parameter is named. -- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Fix kexec x86_64 load failed bug
Huang Ying wrote:
Fix a bug of kexec load on x86_64. Kexec fails to do load on x86_64, with
error message:
Symbol: cmdline_end not found cannot set
Because kexec/arch/i386/kexec-bzImage.c accesses cmdline_end symbol in
i386 purgatory, but there is no cmdline_end in x86_64 purgatory, and
kexec-bzImage.c is used by x86_64 too.
cmdline_end is added into x86_64 purgatory to solve the bug, because kexec
jump support for x86_64 is planned.
Reported-by: Bernhard Walle [EMAIL PROTECTED]
Signed-off-by: Huang Ying [EMAIL PROTECTED]
diff --git a/purgatory/arch/x86_64/purgatory-x86_64.c
b/purgatory/arch/x86_64/purgatory-x86_64.c
index 374b554..67a37f9 100644
--- a/purgatory/arch/x86_64/purgatory-x86_64.c
+++ b/purgatory/arch/x86_64/purgatory-x86_64.c
@@ -5,6 +5,7 @@
uint8_t reset_vga = 0;
uint8_t legacy_pic = 0;
uint8_t panic_kernel = 0;
+char *cmdline_end = 0;
void setup_arch(void)
{
This isn't kernel code? Where is /purgatory/ ?
Anyway, for kernel code, that should be:
char *cmdline_end = NULL;
--
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: why kexec insists on syncing with recent kernels?
On Fri, 8 Feb 2008 11:04:08 -0500 Vivek Goyal wrote:
On Thu, Feb 07, 2008 at 05:59:14PM +0100, Tomasz Chmielewski wrote:
Vivek Goyal schrieb:
On Thu, Feb 07, 2008 at 03:13:30PM +0100, Tomasz Chmielewski wrote:
According to kernel/kexec.c:
* kexec does not sync, or unmount filesystems so if you need
* that to happen you need to do that yourself.
In latest kexec code I do see it syncing. But it does not unmount the
filesystems. So this comment looks like partially wrong.
I saw this was true with 2.6.18 kernel (i.e., it didn't sync), but kexec
syncs with recent kernels (I checked 2.6.23.14 and 2.6.24):
# kexec -e
md: stopping all md devices
sd 2:0:0:0: [sdb] Synchronizing SCSI cache
Which kexec-tools you are using?
# kexec -v
kexec 1.101 released 15 February 2005
syncing is initiated by user space so changing kernel will not have
any effect (as long as user space is same). I think just that message
are spitted by kernel, so probably 2.6.18 did not spit any message and
2.6.24 does.
Yes and no.
I just booted 2.6.24 on a diskless system (Mandriva) I normally use with
2.6.18 kernel, did kexec -e... And it executed the kernel immediately,
without any syncing.
On Debian, with the same 2.6.24 kernel, it does sync.
So what user space part does the syncing (and how to prevent it)?
Syncing is initiated by kexec-tools. Following is the code in
kexec/kexec.c in kexec-tools-testing.tar.gz
if ((result == 0) do_sync) {
sync();
I think this problem has nothing to do with syncing. There seems to be
some dependency on not shutting down network here. You might want to
debug, exactly where does it get stuck.
- Specify earlyprintk= parameter for second kernel and see if control
is reaching to second kernel.
- Otherwise specify --console-serial parameter on kexec -l commandline
and it should display a message I am in purgatory on serial console.
This will just mean that control has reached at least till purgatory.
Right now there does not seem to be any option to prevent syncing and
I don't know why would one like to have one.
(...)
The way kexec works now makes rebooting unreliable again:
- network interfaces are brought down,
- kernel tries to sync - it never will, as we're booted off network,
which is down
Kexec has got an option -x --no-ifdown, which will not bring the network
down. Try that. kexec- -e -x
It does seem to help, thanks.
Why it has to be the last option specified?
I have no idea. This might be an stale comment. Try putting -x before -e.
I tried -f option before (don't call shutdown), but it didn't help.
Even if you did -f, it must have shutdown the network. I think somehow
in latest kernels there is some dependency on network and that's why
not shutting down network in this case is helping you.
I'm seeing NFS mounts take forever to unmount (at shutdown/reboot).
(forever = 1 hour ... or never completes)
Is this similar to the problem that the OP is asking about?
---
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
kexec buffer error
Hi, kexec of 2.6.24-rc6-git11 fails for me with: Close of /boot/kernel-2.6.24-rc6-git11 failed: : buffer error kexec load failed, error = 1 2.6.24-rc6-git9 works as expected. git10 fails with root device not found (for some reason). All have the same kernel config (attached). Any ideas/suggestions? Thanks, --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ kconfig.~1 Description: Binary data ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Fw: [Bugme-new] [Bug 9641] New: kexec userspace utilities cannot handle a kernel command line longer than 256 chars
Begin forwarded message: Date: Wed, 26 Dec 2007 16:26:36 -0800 (PST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 9641] New: kexec userspace utilities cannot handle a kernel command line longer than 256 chars http://bugzilla.kernel.org/show_bug.cgi?id=9641 Summary: kexec userspace utilities cannot handle a kernel command line longer than 256 chars Product: Other Version: 2.5 KernelVersion: 2.6.23 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This doesn't affect the kernel but the userspace utilities from http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/ Since 2.6.21 the maximum length of the kernel command line is 2048 for x86 and x86_64 but the kexec-tools still assume it's 256 therefore a command line longer than 256 chars is truncated upon kexec-reboot. Steps to reproduce: - Boot kernel with a command line longer than 256 chars - cat /proc/cmdline | wc -c - kexec-reboot - cat /proc/cmdline | wc -c -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] add tunable_notifier function ,take2
On Thu, 18 Oct 2007 17:53:00 +0900 Takenori Nagano wrote:
This patch adds new notifier function tunable_notifier_chain. Its base is
atomic_notifier_chain.
Thanks,
---
Signed-off-by: Takenori Nagano [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/kernel/sys.c linux-2.6.23/kernel/sys.c
--- linux-2.6.23.orig/kernel/sys.c2007-10-10 05:31:38.0 +0900
+++ linux-2.6.23/kernel/sys.c 2007-10-18 10:08:52.72800 +0900
@@ -38,6 +38,7 @@
#include linux/syscalls.h
#include linux/kprobes.h
#include linux/user_namespace.h
+#include linux/debugfs.h
#include asm/uaccess.h
#include asm/io.h
@@ -393,6 +394,243 @@ int blocking_notifier_call_chain(struct
EXPORT_SYMBOL_GPL(blocking_notifier_call_chain);
+/**
+ * tunable_atomic_notifier_chain_register
+ * - Add notifier to an tunable notifier chain
Function name short description must be on one (long?) line. :(
+ * @nh: Pointer to head of the tunable notifier chain
+ * @n: New entry in notifier chain
+ * @name: Pointer to the name of the new notifier entry
+ * @desc: Pointer to the description of new entry
+ *
+ * Adds a notifier to an tunable notifier chain and makes control dir.
+ *
+ * Returns zero on success or %-ENODEV on failure.
+ */
+
+int tunable_atomic_notifier_chain_register(
+ struct tunable_atomic_notifier_head *nh,
+ struct tunable_atomic_notifier_block *n, char *name, char *desc)
+{
+}
+
+EXPORT_SYMBOL_GPL(tunable_atomic_notifier_chain_register);
+
+/**
+ * tunable_atomic_notifier_chain_unregister
+ * - Remove notifier from a tunable notifier chain
Ditto.
+ * @nh: Pointer to head of the tunable notifier chain
+ * @n: Entry to remove from notifier chain
+ *
+ * Removes a notifier from a tunable notifier chain.
+ *
+ * Retunrns zero on success or %-ENOENT on failure.
+ */
+
+int tunable_atomic_notifier_chain_unregister(
+ struct tunable_atomic_notifier_head *nh,
+ struct tunable_atomic_notifier_block *n)
+{
+}
+
+EXPORT_SYMBOL_GPL(tunable_atomic_notifier_chain_unregister);
+
+/**
+ * __tunable_atomic_notifier_call_chain
+ * - Call functions in a tunable notifier chain
Same.
+ * @nh: Pointer to head of the tunable notifier chain
+ * @val: Value passed unmodified to notifier function
+ * @v: Pointer passed unmodified to notifier function
+ * @nt_to_call: See the comment for notifier_call_chain
@nr_to_call: ...
+ * @nr_calls: See the comment for notifier_call_chain
+ *
+ * Calls each function in a notifier chain in turn. The functions
+ * run in an atomic context, so they must not block.
+ * This routine uses RCU to synchronize with changes to the chain.
+ *
+ * If the return value of the notifier can be and'ed
+ * with %NOTIFY_STOP_MASK then tunable_atomic_notifier_call_chain()
+ * will return immediately, with the return value of
+ * the notifier function which halted execution.
+ * Otherwise the return value is the return value
+ * of the last notifier function called.
+ */
+
+int __kprobes __tunable_atomic_notifier_call_chain(
+ struct tunable_atomic_notifier_head *nh,
+ unsigned long val, void *v,
+ int nr_to_call, int *nr_calls)
+{
+ int ret;
+
+ rcu_read_lock();
+ ret = notifier_call_chain(nh-head, val, v, nr_to_call, nr_calls);
+ rcu_read_unlock();
+ return ret;
+}
+
+EXPORT_SYMBOL_GPL(__tunable_atomic_notifier_call_chain);
Blank line is usually omitted before EXPORT_SYMBOL
---
~Randy
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2
On Tue, 11 Sep 2007 10:03:43 -0400 Dave Anderson wrote: Vivek Goyal wrote: On Mon, Sep 10, 2007 at 11:35:21AM -0700, Randy Dunlap wrote: On Fri, 7 Sep 2007 17:57:46 +0900 Ken'ichi Ohmichi wrote: Hi, I released a new makedumpfile (version 1.2.0) with vmcoreinfo support. I updated the patches for linux and kexec-tools. PATCH SET: [1/2] [linux-2.6.22] Add vmcoreinfo The patch is for linux-2.6.22. The patch adds the vmcoreinfo data. Its address and size are output to /sys/kernel/vmcoreinfo. [2/2] [kexec-tools] Pass vmcoreinfo's address and size The patch is for kexec-tools-testing-20070330. (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/) kexec command gets the address and size of the vmcoreinfo data from /sys/kernel/vmcoreinfo, and passes them to the second kernel through ELF header of /proc/vmcore. When the second kernel is booting, the kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE segment into /proc/vmcore. Hi, When using the vmcoreinfo patches, what tool(s) are available for analyzing the vmcore (dump) file? E.g., lkcd or crash or just gdb? gdb works for me, but I tried to use crash (4.0-4.6 from http://people.redhat.com/anderson/) and crash complained: crash: invalid kernel virtual address: 0 type: cpu_pda entry Should crash work, or does it need to be modified? Hi Randy, Crash should just work. It might broken on latest kernel. Copying it to crash-utility mailing list. Dave will be able to tell us better. This is on a 2.6.23-rc3 kernel with vmcoreinfo patches and a dump file with -l 31 (dump level 31, omitting all possible pages). There's always the possibility that something crucial (to the crash utility) has changed in the upstream kernel; that's just the nature of the beast. In this case, crash is reading this set of per-cpu pointers: struct x8664_pda *_cpu_pda[NR_CPUS] __read_mostly; and for each one, it then reads the x8664_pda data structure that it points to -- but finds a NULL. It's possible that it has incorrectly determined the number of x8664_pda structures (cpus) that exist. Or less likely, the array contents were read as zeroes from the dumpfile. Anyway, with any initialization-time failure, it's usually helpful to invoke crash with the -d7 (debug level) argument, as in: $ crash -d7 vmlinux vmcore That will display information re: every read made to the dumpfile. In this case, normally you would see, for each cpu, a read of the individual 8-byte address from the array, and then based upon what it read, the subsequent read of the whole 128-byte data structure: readmem: 8042d9c0, KVADDR, _cpu_pda addr, 8, (FOE), 7fb210 readmem: 80406000, KVADDR, cpu_pda entry, 128, (FOE), 937680 CPU0: level4_pgt: 20010 data_offset: 8100899c1000 readmem: 8042d9c8, KVADDR, _cpu_pda addr, 8, (FOE), 7fb210 readmem: 81003ff027c0, KVADDR, cpu_pda entry, 128, (FOE), 937680 CPU1: level4_pgt: 20010 data_offset: 8100899c9000 readmem: 8042d9d0, KVADDR, _cpu_pda addr, 8, (FOE), 7fb210 readmem: 81003ff19e40, KVADDR, cpu_pda entry, 128, (FOE), 937680 CPU2: level4_pgt: 20010 data_offset: 8100899d1000 readmem: 8042d9d8, KVADDR, _cpu_pda addr, 8, (FOE), 7fb210 readmem: 81003ff19640, KVADDR, cpu_pda entry, 128, (FOE), 937680 CPU3: level4_pgt: 20010 data_offset: 8100899d9000 readmem: 8042d9e0, KVADDR, _cpu_pda addr, 8, (FOE), 7fb210 readmem: 80406200, KVADDR, cpu_pda entry, 128, (FOE), 937680 From that data structure it grabs the level4_pgt and data_offset fields for subsequent use. So in your case, it should show how many (if any) of the x8664_pda structures it read before encountering a NULL pointer in one of the array entries. Thanks, Dave. I have the vmcoreinfo patch applied. Kernel is 2.6.23-rc3. The crash debug output is below. Please let me know if you'd like me to test without the vmcoreinfo patch or anything else. --- crash 4.0-4.6 Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc. Copyright (C) 2004, 2005, 2006 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter help copying to see the conditions. This program has absolutely no warranty. Enter help warranty for details. vmcore_data: flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) ndfd: 3 ofp: 322af48760 header_size: 1580 num_pt_load_segments: 4
Re: [Crash-utility] Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2
On Tue, 11 Sep 2007 14:12:00 -0400 Dave Anderson wrote: Randy Dunlap wrote: I have the vmcoreinfo patch applied. Kernel is 2.6.23-rc3. The crash debug output is below. Please let me know if you'd like me to test without the vmcoreinfo patch or anything else. --- [snipped] A few things come to mind. Walking through the debug data above... The very first readmem() from the dumpfile is from the kernel symbol kernel_config_data, where you can see that it found the CONFIG_HZ and CONFIG_NR_CPUS values. The next readmem()'s are of xtime and then init_uts_ns. We don't know what was read from the xtime location, but the utsname data from init_uts_ns gets displayed later on here: utsname version: #19 SMP Tue Sep 4 09:52:06 PDT 2007 And then the linux_banner address of 80537000 is first checked for accessibility (OK), and then it is read successfully, and its contents are displayed here: /proc/version: Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #19 SMP Tue Sep 4 09:52:06 PDT 2007 The string above from the dumpfile is correlated against the linux_banner string in the vmlinux file, which is subsequently displayed here: /boot/vmlinux-2.6.23-rc3: Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #22 SMP Thu Sep 6 21:24:54 PDT 2007 The utsname data and the linux_banner string from the dumpfile are from Tue Sep 4 09:52:06 PDT 2007, whereas the vmlinux file was built 2 days later at Thu Sep 6 21:24:54 PDT 2007. I don't know whether that's the issue or not. Is there a reason that you are *not* using the same vmlinux that the dumpfile was created from? Just sorry user error. Sorry to use your time like that and thanks for the intro-to-crash lesson. It's working now as expected. Thanks. But, for now let's suppose that the two kernels are identical except for the date in the linux_banner strings. I don't have a 2.6.23 kernel source tree handy, but at least as of 2.6.22-5, it was still declared statically like so: struct x8664_pda *_cpu_pda[NR_CPUS] __read_mostly; Has that changed? Nope. If not, it would be worth checking a dumpfile with no pages excluded with makedumpfile. I wouldn't think the in-kernel part of the vmcoreinfo patches would make a difference, but I suppose anything's possible. crash works (loads without error) with the vmcore file and one that has all possible pages removed from it using 'makedumpfile'. But again -- the very first thing to do is make sure that you are using the exact same vmlinux as was booted/dumped. Very true. Thanks again. --- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2
On Fri, 7 Sep 2007 17:57:46 +0900 Ken'ichi Ohmichi wrote: Hi, I released a new makedumpfile (version 1.2.0) with vmcoreinfo support. I updated the patches for linux and kexec-tools. PATCH SET: [1/2] [linux-2.6.22] Add vmcoreinfo The patch is for linux-2.6.22. The patch adds the vmcoreinfo data. Its address and size are output to /sys/kernel/vmcoreinfo. [2/2] [kexec-tools] Pass vmcoreinfo's address and size The patch is for kexec-tools-testing-20070330. (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/) kexec command gets the address and size of the vmcoreinfo data from /sys/kernel/vmcoreinfo, and passes them to the second kernel through ELF header of /proc/vmcore. When the second kernel is booting, the kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE segment into /proc/vmcore. Hi, When using the vmcoreinfo patches, what tool(s) are available for analyzing the vmcore (dump) file? E.g., lkcd or crash or just gdb? gdb works for me, but I tried to use crash (4.0-4.6 from http://people.redhat.com/anderson/) and crash complained: crash: invalid kernel virtual address: 0 type: cpu_pda entry Should crash work, or does it need to be modified? This is on a 2.6.23-rc3 kernel with vmcoreinfo patches and a dump file with -l 31 (dump level 31, omitting all possible pages). Thanks, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] Re: [PATCH 0/2] vmcoreinfo support for dump filtering #2
On Mon, 10 Sep 2007 21:45:43 -0700 Piet Delaney wrote: Vivek Goyal wrote: How do I subscribe to the kexec mailing list on lists.infradead.org? I tried majordomo, as on vger, but it didn't work. See http://lists.infradead.org/mailman/listinfo/kexec --- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [patch 1/3] Express relocatability of kernel on x86_64 in documentation
On Sun, 09 Sep 2007 10:06:21 +0200 Bernhard Walle wrote: This patch adapts the Documentation/kdump/kdump.txt file to express the fact that the x86_64 kernel is now also relocatable. This makes i386 and x86_64 now behave the same, simplifying the documentation. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] Hi, Can we also please reconcile the CRASH_DUMP Kconfig help text? I.e., it says The crash dump kernel must be compiled to a memory address not used by the main kernel or BIOS using PHYSICAL_START. but this ignores the use of RELOCATABLE, right? --- From: Randy Dunlap [EMAIL PROTECTED] Update help text for CONFIG_CRASH_DUMP. Fix typos in CONFIG_RELOCATABLE. Use tab + 2 spaces for indentation on all lines. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- arch/i386/Kconfig | 17 + arch/x86_64/Kconfig | 21 +++-- 2 files changed, 20 insertions(+), 18 deletions(-) --- linux-2.6.23-rc5-git1.orig/arch/i386/Kconfig +++ linux-2.6.23-rc5-git1/arch/i386/Kconfig @@ -820,12 +820,13 @@ config CRASH_DUMP depends on HIGHMEM help Generate crash dump after being started by kexec. - This should be normally only set in special crash dump kernels + This should be normally only set in special crash dump kernels which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. The crash dump kernel must be compiled - to a memory address not used by the main kernel or BIOS using - PHYSICAL_START. + to a memory address not used by the main kernel or BIOS using + PHYSICAL_START, or it must be built as a relocatable image + (CONFIG_RELOCATABLE=y). For more details see Documentation/kdump/kdump.txt config PHYSICAL_START @@ -871,17 +872,17 @@ config PHYSICAL_START Don't change this unless you know what you are doing. config RELOCATABLE - bool Build a relocatable kernel(EXPERIMENTAL) + bool Build a relocatable kernel (EXPERIMENTAL) depends on EXPERIMENTAL help This builds a kernel image that retains relocation information - so it can be loaded someplace besides the default 1MB. + so it can be loaded someplace besides the default 1MB. The relocations tend to make the kernel binary about 10% larger, - but are discarded at runtime. + but are discarded at runtime. One use is for the kexec on panic case where the recovery kernel - must live at a different physical address than the primary - kernel. + must live at a different physical address than the primary + kernel. config PHYSICAL_ALIGN hex Alignment value to which kernel should be aligned --- linux-2.6.23-rc5-git1.orig/arch/x86_64/Kconfig +++ linux-2.6.23-rc5-git1/arch/x86_64/Kconfig @@ -575,17 +575,18 @@ config CRASH_DUMP bool kernel crash dumps (EXPERIMENTAL) depends on EXPERIMENTAL help - Generate crash dump after being started by kexec. - This should be normally only set in special crash dump kernels - which are loaded in the main kernel with kexec-tools into - a specially reserved region and then later executed after - a crash by kdump/kexec. The crash dump kernel must be compiled + Generate crash dump after being started by kexec. + This should be normally only set in special crash dump kernels + which are loaded in the main kernel with kexec-tools into + a specially reserved region and then later executed after + a crash by kdump/kexec. The crash dump kernel must be compiled to a memory address not used by the main kernel or BIOS using - PHYSICAL_START. - For more details see Documentation/kdump/kdump.txt + PHYSICAL_START, or it must be built as a relocatable image + (CONFIG_RELOCATABLE=y). + For more details see Documentation/kdump/kdump.txt config RELOCATABLE - bool Build a relocatable kernel(EXPERIMENTAL) + bool Build a relocatable kernel (EXPERIMENTAL) depends on EXPERIMENTAL help Builds a relocatable kernel. This enables loading and running @@ -596,8 +597,8 @@ config RELOCATABLE must live at a different physical address than the primary kernel. - Note: If CONFIG_RELOCATABLE=y, then kernel run from the address - it has been loaded at and compile time physical address + Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address + it has been loaded at and the compile time physical address (CONFIG_PHYSICAL_START) is ignored. config PHYSICAL_START ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[patch] kexec-tools: fix typos
From: Randy Dunlap [EMAIL PROTECTED] Correct spelling/typos in baud_rate. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- kexec/arch/i386/kexec-x86.c |2 +- kexec/arch/x86_64/kexec-x86_64.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- kexec-tools-testing-20070330.orig/kexec/arch/i386/kexec-x86.c +++ kexec-tools-testing-20070330/kexec/arch/i386/kexec-x86.c @@ -131,7 +131,7 @@ void arch_usage(void) printf( --reset-vga Attempt to reset a standard vga device\n --serial=port Specify the serial port for debug output\n ---serial-baud=buad_rate Specify the serial port baud rate\n +--serial-baud=baud_rate Specify the serial port baud rate\n --console-vga Enable the vga console\n --console-serial Enable the serial console\n --elf32-core-headers Prepare core headers in ELF32 format\n --- kexec-tools-testing-20070330.orig/kexec/arch/x86_64/kexec-x86_64.c +++ kexec-tools-testing-20070330/kexec/arch/x86_64/kexec-x86_64.c @@ -133,7 +133,7 @@ void arch_usage(void) printf( --reset-vga Attempt to reset a standard vga device\n --serial=port Specify the serial port for debug output\n ---serial-baud=buad_rate Specify the serial port baud rate\n +--serial-baud=baud_rate Specify the serial port baud rate\n --console-vga Enable the vga console\n --console-serial Enable the serial console\n ); ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[patch] makedumpfile: fix comments and other strings
From: Randy Dunlap [EMAIL PROTECTED] Fix comment typos and usage messages in makedumpfile.c. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- makedumpfile.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) --- makedumpfile-1.1.6.orig/makedumpfile.c +++ makedumpfile-1.1.6/makedumpfile.c @@ -38,7 +38,7 @@ show_version() } /* - * Convert Physical Address to File Offest. + * Convert Physical Address to File Offset. * If this function returns 0x0, File Offset isn't found. * The File Offset 0x0 is in the ELF header. * It is not in the memory image. @@ -82,7 +82,7 @@ vaddr_to_paddr(unsigned long long vaddr) } /* - * Convert Virtual Address to File Offest. + * Convert Virtual Address to File Offset. * If this function returns 0x0, File Offset isn't found. * The File Offset 0x0 is the ELF header. * It is not in the memory image. @@ -337,7 +337,7 @@ print_usage() MSG( Outputting the dump data in the flattened format to the standard output:\n); MSG( # makedumpfile -F [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE\n); MSG(\n); - MSG( Re-arranging the dump data in the flattened format to a readable DUMPFILE:\n); + MSG( Rearranging the dump data in the flattened format to a readable DUMPFILE:\n); MSG( # makedumpfile -R DUMPFILE\n); MSG(\n); MSG( Generating VMCOREINFO:\n); @@ -390,7 +390,7 @@ print_usage() MSG( Specify VMCOREINFO instead of VMLINUX for analyzing the first kernel's\n); MSG( memory usage.\n); MSG( VMCOREINFO should be made beforehand by makedumpfile with -g option,\n); - MSG( and it containes the first kernel's information. If Dump_Level is 2 or\n); + MSG( and it contains the first kernel's information. If Dump_Level is 2 or\n); MSG( more and [-x VMLINUX] is not specified, this option is necessary.\n); MSG(\n); MSG( [-g VMCOREINFO]:\n); @@ -404,22 +404,22 @@ print_usage() MSG( Output the dump data in the flattened format to the standard output\n); MSG( for transporting the dump data by SSH.\n); MSG( Analysis tools cannot read the flattened format directly. For analysis,\n); - MSG( the dump data in the flattened format should be re-arranged to a readable\n); + MSG( the dump data in the flattened format should be rearranged to a readable\n); MSG( DUMPFILE by -R option.\n); MSG(\n); MSG( [-R]:\n); - MSG( Re-arrange the dump data in the flattened format from the standard input\n); + MSG( Rearrange the dump data in the flattened format from the standard input\n); MSG( to a readable DUMPFILE.\n); MSG(\n); MSG( [--xen-syms XEN-SYMS]:\n); - MSG( Specify the XEN-SYMS to analyze the xen's memory usage.\n); + MSG( Specify the XEN-SYMS to analyze Xen's memory usage.\n); MSG(\n); MSG( [--xen-vmcoreinfo VMCOREINFO]:\n); - MSG( Specify the VMCOREINFO of xen to analyze the xen's memory usage.\n); + MSG( Specify the VMCOREINFO of Xen to analyze Xen's memory usage.\n); MSG(\n); MSG( [--message-level ML]:\n); MSG( Specify the message types.\n); - MSG( Users can restrict outputs printed by specifying Message_Level (ML) with\n); + MSG( Users can restrict output printed by specifying Message_Level (ML) with\n); MSG( this option. The message type marked with an X in the following table is\n); MSG( printed to standard error output. For example, according to the table,\n); MSG( specifying 7 as ML means progress indicator, common message, and error\n); @@ -463,8 +463,8 @@ print_usage() MSG(\n); MSG( XEN-SYMS:\n); MSG( This is a pathname to the xen-syms.\n); - MSG( This file must have the debug information of the xen to analyze the\n); - MSG( xen's memory usage.\n); + MSG( This file must have the debug information of Xen to analyze\n); + MSG( Xen's memory usage.\n); MSG(\n); } @@ -580,7 +580,7 @@ open_files_for_generating_vmcoreinfo() } /* - * Open the following file when it re-arranges the dump data. + * Open the following file when it rearranges the dump data. * - dump file */ int @@ -901,8 +901,8 @@ get_elf_info() /* * FIXME -* If the page_size of 1st-kernel is different from the one of -* capture(2nd)-kernel, the problem will happen. +* If the page_size of 1st kernel is different from the one of +* capture(2nd) kernel, the problem will happen. */ info-page_size = sysconf(_SC_PAGE_SIZE); info-page_shift = ffs(info-page_size) - 1; @@ -2768,7 +2768,7 @@ get_mm_discontigmem
[patch] makedumpfile: update/clarify README
On Mon, 3 Sep 2007 16:57:08 +0900 [EMAIL PROTECTED] wrote: Makefile installs ld command etc. and they influence kernel build. We installed elfutils-0.125 not by 'make install' but by procedure written at README of makedumpfile-1.1.6 in RHEL5.0 environment. Please uninstall elfutils-0.125 and elfutils-0.128 and try the above procedure. Hi tachibana-san, Thanks for that info. I completely missed that in the README file. Please update the README file with this patch. --- From: Randy Dunlap [EMAIL PROTECTED] Warn not to use make install for elfutils. Fix a few typos. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- README | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) --- makedumpfile-1.1.6.orig/README +++ makedumpfile-1.1.6/README @@ -4,11 +4,13 @@ == * REQUIREMENTS - Please download the following library file and install it: + Please download the following library file and install it exactly as below; + do NOT use make install. - elfutils-0.125.tar.gz The make install of elfutils installs some commands (ld, readelf, etc.), -and the compiling problem sometimes happens due to using the installed -commands. To install only the library files, do the following method. +and compiling problems sometimes happen due to using the installed +commands. To install only the library header files, use the following +method: # tar -zxvf elfutils-0.125.tar.gz # cd elfutils-0.125 # ./configure @@ -85,8 +87,8 @@ make: *** [makedumpfile] Error 1 # -The compiler cannot find out elf_getshstrndx() because it tries -searching it only from /usr/lib/libelf.a though elf_getshstrndx() +The compiler cannot find elf_getshstrndx() because it tries +searching for it only from /usr/lib/libelf.a though elf_getshstrndx() is archived in /usr/local/lib/libelf.a. To solve the problem, add the option (-L/usr/local/lib/) to CFLAGS of Makefile like the following: @@ -104,4 +106,3 @@ Ken'ichi Ohmichi [EMAIL PROTECTED] Masaki Tachibana [EMAIL PROTECTED] kexec-ml kexec@lists.infradead.org - ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] makedumpfile-1.1.4-rc: ia64 DISCONTIGMEM support
On Mon, 3 Sep 2007 16:57:08 +0900 [EMAIL PROTECTED] wrote: Makefile installs ld command etc. and they influence kernel build. We installed elfutils-0.125 not by 'make install' but by procedure written at README of makedumpfile-1.1.6 in RHEL5.0 environment. Please uninstall elfutils-0.125 and elfutils-0.128 and try the above procedure. Hi tachibana-san, I have makedumpfile filtering working now. Much thanks. Examples of filtering on a 1 GB x86_64 system, booted with [EMAIL PROTECTED] and then crashed (sysrq-c). Various makedumpfile -d values and their results: makedumpfile -d 1 -E -i vmcore.info vmcore.002 dump002.omit.zero makedumpfile -d 17 -E -i vmcore.info vmcore.002 dump002.omit.zero.free makedumpfile -d 23 -E -i vmcore.info vmcore.002 dump002.omit.zero.free.all.cache makedumpfile -d 31 -E -i vmcore.info vmcore.002 dump002.omit.all -r 1 rddunlap users970M Sep 4 12:36 vmcore.002 // dumpfile -rw--- 1 rddunlap rddunlap 966M Sep 4 15:10 dump002.omit.zero -rw--- 1 rddunlap rddunlap 661M Sep 4 15:29 dump002.omit.zero.free -rw--- 1 rddunlap rddunlap 443M Sep 4 15:43 dump002.omit.zero.free.all.cache -rw--- 1 rddunlap rddunlap 429M Sep 4 15:55 dump002.omit.all Regards, --- ~Randy ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] makedumpfile-1.1.4-rc: ia64 DISCONTIGMEM support
On Fri, 31 Aug 2007 22:07:28 +0900 [EMAIL PROTECTED] wrote: Hi Randy, On Thu, 30 Aug 2007 12:58:05 -0700, Randy Dunlap [EMAIL PROTECTED] wrote: On Thu, 30 Aug 2007 12:49:51 -0700 Randy Dunlap wrote: On Fri, 1 Jun 2007 18:11:14 +0900 Ken'ichi Ohmichi wrote: Hi, The attached patch is for the development, and it isn't stable yet. This patch can be applied to makedumpfile version 1.1.3. If you find some problems in this patch, please let me know. If there aren't any problems, I will release a new makedumpfile by next weekend. diff -puN backup/v1.1.3/README makedumpfile/README --- backup/v1.1.3/README2007-04-13 15:44:55.0 +0900 +++ makedumpfile/README 2007-06-01 13:05:19.0 +0900 @@ -3,6 +3,10 @@ makdumpfile's README == +* REQUIREMENTS + Please download the following library file and install it: + - elfutils-0.125.tar.gz + Is elfutils-0.125 (precisely that version number) required, or Yes. Please use the specified version. Hi, I did that, but I still cannot build a kernel, although the problem is different now. The build fails with: Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Error 1 even after I set/enable CONFIG_KALLSYMS_EXTRA_PASS. Have you tested this on x86_64? Thanks. could this be elfutils-0.125.tar.gz or later? I.e., is there something special/specific about elfutils-0.125 ? It's a bit difficult to find 0.125 on the internet... The reason that I ask the question(s) is that after I build elfutils-0.128 and then do 'make install', I can no longer build a kernel, i.e., kernel 'make' has errors, like: CC init/main.o CC init/do_mounts.o CC init/do_mounts_rd.o AS usr/initramfs_data.o LD usr/built-in.o ld: cannot load ld backend library 'libld_elf_x86_64.so': libld_elf_x86_64.so: cannot open shared object file: No such file or directory make[1]: *** [usr/built-in.o] Error 1 make: *** [usr] Error 2 make: *** Waiting for unfinished jobs CC init/do_mounts_initrd.o CC init/initramfs.o CC init/calibrate.o CC init/version.o LD init/mounts.o ld: cannot load ld backend library 'libld_elf_x86_64.so': libld_elf_x86_64.so: cannot open shared object file: No such file or directory make[1]: *** [init/mounts.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [init] Error 2 on x86_64. * BUILD INSTALL 1.Get the latest makedumpfile from the following site: https://sourceforge.net/projects/makedumpfile/ --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] makedumpfile-1.1.4-rc: ia64 DISCONTIGMEM support
On Fri, 31 Aug 2007 09:49:28 -0700 Randy Dunlap wrote: On Fri, 31 Aug 2007 22:07:28 +0900 [EMAIL PROTECTED] wrote: Hi Randy, On Thu, 30 Aug 2007 12:58:05 -0700, Randy Dunlap [EMAIL PROTECTED] wrote: On Thu, 30 Aug 2007 12:49:51 -0700 Randy Dunlap wrote: On Fri, 1 Jun 2007 18:11:14 +0900 Ken'ichi Ohmichi wrote: Hi, The attached patch is for the development, and it isn't stable yet. This patch can be applied to makedumpfile version 1.1.3. If you find some problems in this patch, please let me know. If there aren't any problems, I will release a new makedumpfile by next weekend. diff -puN backup/v1.1.3/README makedumpfile/README --- backup/v1.1.3/README 2007-04-13 15:44:55.0 +0900 +++ makedumpfile/README 2007-06-01 13:05:19.0 +0900 @@ -3,6 +3,10 @@ makdumpfile's README == +* REQUIREMENTS + Please download the following library file and install it: + - elfutils-0.125.tar.gz + Is elfutils-0.125 (precisely that version number) required, or Yes. Please use the specified version. Hi, I did that, but I still cannot build a kernel, although the problem is different now. The build fails with: Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Error 1 even after I set/enable CONFIG_KALLSYMS_EXTRA_PASS. Have you tested this on x86_64? Sorry about this. Above was with the distro-installed 'ld' instead of the one built from elfutils-0.125. When I correct this, build fails like this: CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h SYSCALL arch/x86_64/vdso/vdso.so /usr/local/bin/ld: unrecognized option `--hash-style=gnu' Try `ld --help' or `ld --usage' for more information. collect2: ld returned 64 exit status make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1 make: *** [arch/x86_64/vdso] Error 2 make: *** Waiting for unfinished jobs SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so /usr/local/bin/ld: unrecognized option `--hash-style=gnu' Try `ld --help' or `ld --usage' for more information. collect2: ld returned 64 exit status make[1]: *** [arch/x86_64/ia32/vsyscall-sysenter.so] Error 1 make: *** [arch/x86_64/ia32] Error 2 Thanks. could this be elfutils-0.125.tar.gz or later? I.e., is there something special/specific about elfutils-0.125 ? It's a bit difficult to find 0.125 on the internet... The reason that I ask the question(s) is that after I build elfutils-0.128 and then do 'make install', I can no longer build a kernel, i.e., kernel 'make' has errors, like: CC init/main.o CC init/do_mounts.o CC init/do_mounts_rd.o AS usr/initramfs_data.o LD usr/built-in.o ld: cannot load ld backend library 'libld_elf_x86_64.so': libld_elf_x86_64.so: cannot open shared object file: No such file or directory make[1]: *** [usr/built-in.o] Error 1 make: *** [usr] Error 2 make: *** Waiting for unfinished jobs CC init/do_mounts_initrd.o CC init/initramfs.o CC init/calibrate.o CC init/version.o LD init/mounts.o ld: cannot load ld backend library 'libld_elf_x86_64.so': libld_elf_x86_64.so: cannot open shared object file: No such file or directory make[1]: *** [init/mounts.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [init] Error 2 on x86_64. * BUILD INSTALL 1.Get the latest makedumpfile from the following site: https://sourceforge.net/projects/makedumpfile/ --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec+kdump + vmcoreinfo patch
On Fri, 24 Aug 2007 14:41:47 -0700 Randy Dunlap wrote: Hi, I'm trying to use the recent vmcoreinfo patch... c. My 2.6.23-rc3 dump-capture kernel currently faults a few times, then it panics. I'll add a serial console and capture its output to see what is going on. I booted 3 times with no problems (without serial console on the dump-capture kernel), then I added a serial console to that kernel and got lots of problems. They all seem to be OOM problems, then the kernel gives up and falls over. (log attached) d. Documentation/kdump/kdump.txt mentions an option to produce ELF32 headers instead of 64-bit headers: --elf32-core-headers. Where is this option used? I.e., what program recognizes it? kdump.txt isn't telling me this info and I can't read it between the lines. Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** SysRq : Trigger a crashdump Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #5 SMP Thu Aug 23 15:51:37 PDT 2007 Command line: root=/dev/hda8 maxcpus=1 irqpoll 3 console=ttyS0,115200n8 memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] elfcorehdr=81904K memmap=56K#1048320K memmap=136K#1048376K BIOS-provided physical RAM map: BIOS-e820: 0100 - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 3ffc (usable) BIOS-e820: 3ffc - 3ffce000 (ACPI data) BIOS-e820: 3ffce000 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fecc - fecc1000 (reserved) BIOS-e820: ff78 - 0001 (reserved) end_pfn_map = 1048576 user-defined physical RAM map: user: - 000a (usable) user: 010a - 04ffc000 (usable) user: 3ffc - 3ffce000 (ACPI data) user: 3ffce000 - 3fff (ACPI data) end_pfn_map = 262128 DMI 2.3 present. ACPI: RSDP 000F87C0, 0014 (r0 ACPIAM) ACPI: RSDT 3FFC, 0034 (r1 A M I OEMRSDT 9000528 MSFT 97) ACPI: FACP 3FFC0200, 0084 (r2 A M I OEMFACP 9000528 MSFT 97) ACPI: DSDT 3FFC0440, 45ED (r1 12345 12345123 123 INTL 2002026) ACPI: FACS 3FFCE000, 0040 ACPI: APIC 3FFC0390, 0068 (r1 A M I OEMAPIC 9000528 MSFT 97) ACPI: MCFG 3FFC0400, 003C (r1 A M I OEMMCFG 9000528 MSFT 97) ACPI: OEMB 3FFCE040, 0046 (r1 A M I AMI_OEM 9000528 MSFT 97) Scanning NUMA topology in Northbridge 24 CPU has 1 num_cores No NUMA configuration found Faking a node at -04ffc000 Bootmem setup node 0 -04ffc000 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 - 160 0: 4256 -20476 Looks like a VIA chipset. Disabling IOMMU. Override with iommu=allowed ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x02] address[0xfecc] gsi_base[24]) IOAPIC[1]: apic_id 2, address 0xfecc, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 3fff:c001) SMP: Allowing 2 CPUs, 1 hotplug CPUs PERCPU: Allocating 428296 bytes of per cpu data Built 1 zonelists in Node order. Total pages: 15893 Policy zone: DMA32 Kernel command line: root=/dev/hda8 maxcpus=1 irqpoll 3 console=ttyS0,115200n8 memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] elfcorehdr=81904K memmap=56K#1048320K memmap=136K#1048376K Misrouted IRQ fixup and polling support enabled This may significantly impact system performance Initializing CPU#0 PID hash table entries: 256 (order: 8, 2048 bytes) time.c: Detected 1000.063 MHz processor. Console: colour dummy device 80x25 console [ttyS0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1712 kB per task-struct memory footprint: 2160 bytes Memory: 52624k/81904k available (3234k kernel code, 12896k reserved, 1776k data, 720k init) Calibrating delay using timer
