On Mon, Jun 09, 2008 at 12:01:15AM +0200, Johannes Weiner wrote:
Hi,
Bernhard Walle [EMAIL PROTECTED] writes:
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -798,12 +798,13 @@ void free_initrd_mem(unsigned long start
}
#endif
-void __init
* Vivek Goyal [2008-06-09 09:22]:
Kdump first kernel always tries to reserve just physical RAM and nothing
else. So I am not sure what does above code do. Try to reserve a memory
which is not RAM but is in the region less than highest mapped entity and
in that case return silently without any
* Johannes Weiner [2008-06-09 00:01]:
/*
@@ -811,11 +812,11 @@ void __init reserve_bootmem_generic(unsi
* firmware tables:
*/
if (pfn max_pfn_mapped)
- return;
+ return -EFAULT;
This seemed to
* Johannes Weiner [2008-06-09 00:06]:
+
#else
reserve_bootmem(phys, len, BOOTMEM_DEFAULT);
^^^ flags?
And you ignore the return value here.
Thanks for catching that. Updated patch:
Bernhard Walle wrote:
* Vivek Goyal [2008-06-09 09:22]:
Kdump first kernel always tries to reserve just physical RAM and nothing
else. So I am not sure what does above code do. Try to reserve a memory
which is not RAM but is in the region less than highest mapped entity and
in that case
On Mon, 2008-06-09 at 18:39 +0200, Andi Kleen wrote:
Bernhard Walle wrote:
* Vivek Goyal [2008-06-09 09:22]:
Kdump first kernel always tries to reserve just physical RAM and nothing
else. So I am not sure what does above code do. Try to reserve a memory
which is not RAM but is in the
* Amul Shah [EMAIL PROTECTED] [2008-06-09 15:50]:
Don't remember the details. Perhaps Amul does (cc'ed)
-Andi
The short story is that the kexec kernel was panicking when trying to
reserve the MP tables. The panic occurs because the MP tables resided
in a reserved memory area
On Mon, Jun 09, 2008 at 10:17:32PM +0200, Bernhard Walle wrote:
* Amul Shah [EMAIL PROTECTED] [2008-06-09 15:50]:
Don't remember the details. Perhaps Amul does (cc'ed)
-Andi
The short story is that the kexec kernel was panicking when trying to
reserve the MP tables. The
Hi Vivek,
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:29]:
Can you please put some more explanation comment here to explain that
why it is ok to return with success, despite the fact that we never
reserved any memory.
Do you think that's ok?
When booting the kdump kernel, the MP
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:54]:
On Mon, Jun 09, 2008 at 10:42:11PM +0200, Bernhard Walle wrote:
Hi Vivek,
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:29]:
Can you please put some more explanation comment here to explain that
why it is ok to return with
On Mon, Jun 09, 2008 at 10:57:34PM +0200, Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:54]:
On Mon, Jun 09, 2008 at 10:42:11PM +0200, Bernhard Walle wrote:
Hi Vivek,
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:29]:
Can you please put some more
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 17:00]:
I am really not sure. :-). In the past, Andrew picked up the patches, kept
in his tree for couple of days and if something is important, he will push
it out to Linus.
Ok, I'm a bit confused about linux-next, and the new x86 tree from
Hi,
Bernhard Walle [EMAIL PROTECTED] writes:
This patch adds a 'flags' parameter to reserve_bootmem_generic() like it
already has been added in reserve_bootmem() with commit
72a7fe3967dbf86cb34e24fbf1d957fe24d2f246.
It also changes all users to use BOOTMEM_DEFAULT, which doesn't effectively
13 matches
Mail list logo
