Re: [PATCH]IA64: do not include uncached memory to vmcore

On Fri, Sep 12, 2008 at 01:10:34PM -0700, Jay Lan wrote: > 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 u

[PATCH]IA64: do not include uncached memory to vmcore

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 may MCA when it

Re: the exiting makedumpfile is almost there... :)

Dave Anderson wrote: > Try using at least -d4 and redirect the output to a file. It's much > more verbose than the above, but it shows every readmem() made from > the dumpfile: > > # crash -d4 vmlinux vmcore.cp > /tmp/debug.cp > q > # crash -d4 vmlinux vmcore.makedumpfile > /tmp/debug.makedump

Re: the exiting makedumpfile is almost there... :)

Jay Lan wrote: > Jay Lan wrote: > >>Ken'ichi Ohmichi wrote: >> >>>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 creati

Re: the exiting makedumpfile is almost there... :)

Jay Lan wrote: > Ken'ichi Ohmichi wrote: >> 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 >>> >>> >>> |

Re: [patch kexec] Fix test for loaded kernel

Hi Simon, Sorry, this does not work correctly. Please ignore. Geoff Levand wrote: > Fix these reboot errors with NFS mounted root filesystems: > > nfs: server 192.168.1.1 not responding, still trying > > The main kexec code that uses kexec_loaded() expects a non-zero > return to mean a kex

[patch kexec] Fix test for loaded kernel

Fix these reboot errors with NFS mounted root filesystems: nfs: server 192.168.1.1 not responding, still trying The main kexec code that uses kexec_loaded() expects a non-zero return to mean a kexec kernel has been loaded for execution. Here is the current check: if ((result == 0) &&

Re: SetVirtualAddressMap() on Tiano EFI firmware

On Thursday 11 September 2008 03:59:54 pm Lombard, David N wrote: > 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 SetVirtualAddres

Re: [PATCH]IA64: assign a distinguishable label to uncached memory in /proc/iomem

Bernhard Walle wrote: > * Bernhard Walle <[EMAIL PROTECTED]> [2008-09-12]: > >> Isn't that too much indent, i.e. shouldn't that be > > Of course Yep! Thanks for correction. jay > > --- a/arch/ia64/kernel/efi.c > +++ b/arch/ia64/kernel/efi.c > @@ -1232,9 +1232,10 @@ efi_initialize_iomem_resou

Re: the exiting makedumpfile is almost there... :)

Ken'ichi Ohmichi wrote: > 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 pgt

Re: [PATCH]IA64: assign a distinguishable label to uncached memory in /proc/iomem

* Bernhard Walle <[EMAIL PROTECTED]> [2008-09-12]: > Isn't that too much indent, i.e. shouldn't that be Of course --- a/arch/ia64/kernel/efi.c +++ b/arch/ia64/kernel/efi.c @@ -1232,9 +1232,10 @@ efi_initialize_iomem_resources(struct re if (md->attribute & EFI_MEM

Re: [PATCH]IA64: assign a distinguishable label to uncached memory in /proc/iomem

* Jay Lan <[EMAIL PROTECTED]> [2008-09-11]: > - } else { > - name = "System RAM"; > - } > + } else if (md->attribute == EFI_MEMORY_UC) > +