On Fri, 2009-01-02 at 16:18 -0800, Trent Piepho wrote:
> 2.6.28 is out, can my existing patches be accepted?
It's all FSL stuff and thus in Kumar's hands. I think there's a pending
pull request from him tho, thus maybe they are in there already :-)
I've just officially taken over so I'll scrub pa
2.6.28 is out, can my existing patches be accepted?
[2/2] POWERPC/fsl-pci: Set relaxed ordering on prefetchable ranges
http://patchwork.ozlabs.org/patch/14546/
[1/2] POWERPC/fsl-pci: Better ATMU setup
http://patchwork.ozlabs.org/patch/14544/
[5/5] powerpc: booke: Allow larger CAM sizes than 256
Instead of fetching data from the segment array, remember the address
when added and find the kernel text from the parsed elf header.
While add_segment (and hence add_buffer) always adds to the end of
the list of segments, it sorts the previous segments before each
allocation. In some layouts, th
don't copy purgatory, as elf-load-rel does that for us (like x86_64).
move function declarations from c to h files
remove casts between void * and various pointers
change some pointers between char and unsigned char *
change args to be vars of the right type instead of casting or
copying betwe
The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.
We now need to set a flag in the kernel image. Since we only have
the kernel image avialable as const data to kexec-tools c code, set
the flag in the copy we put in purgatory, and have it set the flag
in the ker
The kexec info struct defines entry to be a void *, so pass around the
user supplied value as one.
This fixes the following warning:
gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include
-I./util_lib/include -Iinclude/ -I./kexec/arch/ppc64/include -c -MD -o
kexec/kexec.o kexec/
make the idom "always call realloc_memory_ranges when filling a range entry"
kexec was core dumping after using 5 exclude_range pairs when only 3
were allocated.
also delcare realloc_memory_ranges to take no arguments.
Signed-off-by: Milton Miller
Index: kexec-tools/kexec/arch/ppc64/kexec-ppc6
Enforce that the crash kernel region never overlaps the current kernel,
as it will be written directly on kexec load.
Also, default to the previous KDUMP_KERNELBASE if the start is 0.
Other architectures (x86, ia64) state that specifying the start address
0 (or omitting it) will result in the ker
We are declaring the dummy section (used to work around a binutils
bug) as PT_NOTE, but we don't have enough bytes for it to be a valid
note header, and kexec userspace complains:
Warning: Elf Note name is not null terminated
Warning: append= option is not passed. Using the first kernel root parti
Subject [PATCH kexec-tools 5/5] entry wants to be void *
Date: Fri, 02 Jan 2009 14:44:40 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102
The kexec info struct defines entry to be a void *, so pass around the
user supplied value as one.
This fixes the following warning:
gcc -
Subject [PATCH kexec-tools 4/5] ppc64: cleanups
Date: Fri, 02 Jan 2009 14:44:26 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102
don't copy purgatory, as elf-load-rel does that for us (like x86_64).
move function declarations from c to h files
remove casts between void * and
Subject [PATCH kexec-tools 3/5] ppc64: segments may be reordered
Date: Fri, 02 Jan 2009 14:44:13 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102
Instead of fetching data from the segment array, remember the address
when added and find the kernel text from the parsed elf header
Subject [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable
kernel
Date: Fri, 02 Jan 2009 14:44:01 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102
The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.
We now need to set a flag i
Subject [PATCH kexec-tools 1/5] ppc64: always check number of ranges when adding
Date: Fri, 02 Jan 2009 14:43:49 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102
make the idom "always call realloc_memory_ranges when filling a range entry"
kexec was core dumping after using 5 e
Follwing this mail are 5 patches for kexec userspace and two for the
kernel. The first fixes an array overflow and the second updates
userspace to the merged 2.6.28 kdump support. The remaining are
cleanups and warning fixes, including one for the common code.
The two patchs for the kernel are i
On Jan 2, 2009, at 8:08 AM, M. Mohan Kumar wrote:
Support for relocatable kernel in kexec-tools
This patch is based on the patch sent by Milton Miller with the
subject [PATCH 1/2
kexec-tools] ppc64: new relocatble kernel activation ABI
http://patchwork.ozlabs.org/patch/5378/
Even with th
Enable RELOCATABLE option if user selects CRASH_DUMP option. Without this
patch user has to first select RELOCATABLE option and then has to enable
CRASH_DUMP option.
Signed-off-by: M. Mohan Kumar
---
arch/powerpc/Kconfig |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thu, Jan 1, 2009 at 9:40 PM, Paul Mackerras wrote:
> Ben Herrenschmidt is taking over as the primary powerpc architecture
> maintainer. I'll still be around as his backup/deputy.
>
> Signed-off-by: Paul Mackerras
Yeah, I *guess* I can follow Ben. :-P
Acked-by: Grant Likely
> ---
> Now wi
Support for relocatable kernel in kexec-tools
This patch is based on the patch sent by Milton Miller with the subject [PATCH
1/2
kexec-tools] ppc64: new relocatble kernel activation ABI
http://patchwork.ozlabs.org/patch/5378/
Even with the above patch, the relocatable kernel always move to ph
Hi,
2.6.28-git4 kernel drops to xmon with kernel expection. Similar kernel
expection was seen next-20081230 and next-20081231 and was reported
earlier at http://lkml.org/lkml/2008/12/31/157
1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c002763cb700]
pc: c00e2c54: .kmem_
21 matches
Mail list logo
