On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
Hi Ananth,
Today's linux-next build (powerpc allyesconfig) failed like this:
tests/lkdtm.c:182: error: expected ')' before '*' token
I have no idea why this fails now when it did not before.
Sorry, that's my fault.
(I
On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
Hi Ananth,
Today's linux-next build (powerpc allyesconfig) failed like this:
tests/lkdtm.c:182: error: expected ')' before '*' token
I have no idea why
Hi,
We have been facing a number of kdump issues on quite a few of our
hardware. These are with RT kernel as the kdump kernel. Inorder to keep
discussion about each hardware separate, sending separate mails for each
as part of the same thread.
Pl let me know if I need to provide more
On Wed, Jul 30, 2008 at 09:15:10AM +1000, Simon Horman wrote:
After recent patches* is_kdump_kernel() should return 1 in the
case where code is executing in a crashkernel and 0 otherwise.
It is safe to use outside of CONFIG_CRASH_DUMP.
* http://lkml.org/lkml/2008/7/28/445
Signed-off-by:
On Wed, Jul 30, 2008 at 10:30:28AM +1000, Simon Horman wrote:
IA64, PPC and SH also support the elfcorehdr command line.
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/Documentation/kernel-parameters.txt
===
On Tue, Jul 29, 2008 at 06:12:38PM +1000, Simon Horman wrote:
After recent changes setting elfcorehdr_addr to ELFCORE_ADDR_MAX
will cause is_kdump_kernel() to return 0 when it should return 1.
Instead use vmcore_unusable(), which has been added for this purpose.
Signed-off-by: Simon Horman
On Wednesday 30 July 2008, Ankita Garg wrote:
On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
Hi Ananth,
Today's linux-next build (powerpc allyesconfig) failed like this:
tests/lkdtm.c:182: error:
This patch series fixes coding style and also moves initialisation of kobject
to a safe point of time.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Because kobject_init() call could be done from firmware_map_add_entry()
which is called before kmalloc() can be used (we use the early bootmem allocator
here), move that call to memmap_init() which is a late_initcall.
This fixes following regression in linux-next tree:
BUG: Int 14: CR2
On Wed, 30 Jul 2008 22:14:24 +0200
Bernhard Walle [EMAIL PROTECTED] wrote:
* Bernhard Walle [EMAIL PROTECTED] [2008-07-30 22:12]:
Because kobject_init() call could be done from firmware_map_add_entry()
which is called before kmalloc() can be used (we use the early bootmem
allocator
* Andrew Morton [EMAIL PROTECTED] [2008-07-30 13:40]:
If you think that firmware/memmap: Move kobject initialisation before
kobject_add()
Yes, that's what I meant.
should still be applied then I'd disagree. Adding a
GFP_KERNEL allocation into kobject_init() was a fairly significant
Hi,
We have been using RT kernel as the kdump kernel for most of our work.
This was working fine on 2.6.21.4-rt10 RT kernel. After which, we moved
over to 2.6.24-rt1 RT kernel. Now, the kdump kernel hangs. Attaching the
complete kdump kernel boot log with initcall_debug option passed to the
kdump
Hi,
We have been using RT kernel as the kdump kernel for most of our work.
This was working fine on 2.6.21.4-rt10 RT kernel. After which, we moved
over to 2.6.24-rt1 RT kernel. Now, the kdump kernel hangs. Attaching the
complete kdump kernel boot log with initcall_debug option passed to the
kdump
Hi Bart,
On Wed, 30 Jul 2008 21:16:55 +0200 Bartlomiej Zolnierkiewicz [EMAIL
PROTECTED] wrote:
On Wednesday 30 July 2008, Ankita Garg wrote:
On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
Hi Ananth,
On Wed, Jul 30, 2008 at 09:01:31AM -0400, Vivek Goyal wrote:
On Tue, Jul 29, 2008 at 06:12:38PM +1000, Simon Horman wrote:
After recent changes setting elfcorehdr_addr to ELFCORE_ADDR_MAX
will cause is_kdump_kernel() to return 0 when it should return 1.
Instead use vmcore_unusable(), which
A quick cut and paste from other architectures to allow SH
to parse the elfcorehdr command line argument which is required
for both is_kdump_kernel() and vmcore to function.
(the former is as yet unused on SH).
Tested compilation only
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Andrew,
From: Vivek Goyal [EMAIL PROTECTED]
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous
After recent changes setting elfcorehdr_addr to ELFCORE_ADDR_MAX
will cause is_kdump_kernel() to return 0 when it should return 1.
Instead use vmcore_unusable(), which has been added for this purpose.
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Andrew, this can wait until post 2.6.27 as
Hi,
this patch series contains all the patches (that I am aware of)
that have recently been posted regarding kdump and in particular
is_kdump_kernel()
For Andrew Morton's benefit I have annotated each patch as to whether it
needs to be included in 2.6.27 or not. My conclusion is that while
I
IA64, PPC and SH also support the elfcorehdr command line.
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Acked-by: Vivek Goyal [EMAIL PROTECTED]
---
Andrew, as this is a very minor documentation fix it can wait until
after 2.6.27 if you prefer.
Index:
20 matches
Mail list logo
