Hi Hedi, Jay,
Hedi Berriche wrote:
> In addition to what other folks have mentioned about giving the latest crash
> version a try, I'd like to point out that makedumpfile did spit a couple of
> warnings while creating the vmcore
>
>
> | Can't distinguish the pgtable.
> | The kernel version is n
Hi Bernhard,
Good catching :-)
This patch also will be merged to the next release.
Thanks
Ken'ichi Ohmichi
Bernhard Walle wrote:
> This memory leaks appear in valigrind run:
>
> makedumpfile Completed.
> ==6024==
> ==6024== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 f
Hi Bernhard,
Thank you for the patch.
It will be merged to the next release.
Thanks
Ken'ichi Ohmichi
Bernhard Walle wrote:
> Because of structure member alignment, the simple structure
>
> struct kdump_sub_header {
> unsigned long phys_base;
> int dum
On Wed, Sep 10, 2008 at 06:40:46PM -0700, Geoff Levand wrote:
> Fix these ppc64 32 bit build warnings:
>
> kexec/arch/ppc64/kexec-zImage-ppc64.c: In function 'zImage_ppc64_load':
> kexec/arch/ppc64/kexec-zImage-ppc64.c:164: warning: cast to pointer from
> integer of different size
> kexec/arch
On Wed, Sep 10, 2008 at 06:40:42PM -0700, Geoff Levand wrote:
> Fix these 64 bit build warnings:
>
> kexec/firmware_memmap.c:241: warning: format '%d' expects type 'int', but
> argument 3 has type 'size_t'
> kexec/crashdump-elf.c:160: warning: format '%llx' expects type 'long long
> unsigned i
Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
is denoted as "System RAM" in /proc/iomem, while memory of attribute
(EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
The kexec utility then includes uncached memory as part of vmcore. The
kdump kernel MCA'ed when it t
On Thu, Sep 11, 2008 at 01:23:58PM -0700, Bjorn Helgaas wrote:
> Has kexec been tested on x86 with EFI firmware?
>
> I'm testing it on ia64 with Tiano-based EFI firmware, and I
> tripped over an issue with SetVirtualAddressMap(). I would
> expect a similar problem to happen on x86, but I don't se
Has kexec been tested on x86 with EFI firmware?
I'm testing it on ia64 with Tiano-based EFI firmware, and I
tripped over an issue with SetVirtualAddressMap(). I would
expect a similar problem to happen on x86, but I don't see
any code to deal with it.
The EFI SetVirtualAddressMap() interface is
This memory leaks appear in valigrind run:
makedumpfile Completed.
==6024==
==6024== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==6024== malloc/free: in use at exit: 8,838 bytes in 5 blocks.
==6024== malloc/free: 80 allocs, 75 frees, 192,858 bytes allocated
On Thu, Sep 11, 2008 at 00:29 Jay Lan wrote:
| a4700rac:/boot # date; makedumpfile -c -d31 -x
| /boot/vmlinux-2.6.27-rc5-default /proc/vmcore
| /mnt/sda9/diskdump/vmcore-2.6.27-rc5-default; date
| Wed Sep 10 14:31:56 PDT 2008
| Can't distinguish the pgtable.
| The k
Jay Lan wrote:
> After getting around a few kdump kernel panic/hang, i finally was
> able to complete a kdump vmcore with 2.6.27-rc5. The system under
> testing was an IA64 with 128 cpu and 256G memory A4700 system.
>
> The /proc/vmcore is:
> a4700rac:/boot # ll /proc/vmcore
> -r 1 root ro
Because of structure member alignment, the simple structure
struct kdump_sub_header {
unsigned long phys_base;
int dump_level;
};
is 16 bytes large on x86_64. So if you fill the two members phys_base and
dump_level with values, you still have u
* "Ken'ichi Ohmichi" <[EMAIL PROTECTED]> [2008-09-11]:
>
> I have not tested makedumpfile on IA64 linux-2.6.27-rcX yet,
> because IA64 linux-2.6.27-rcX kernel gets a panic while booting.
> So I guess that there is some thing wrong in my .config file.
http://article.gmane.org/gmane.linux.ports.i
13 matches
Mail list logo
