diff options
author | Anton Vorontsov <avorontsov@ru.mvista.com> | 2008-12-17 10:09:10 +0000 |
---|---|---|
committer | Paul Mackerras <paulus@samba.org> | 2008-12-23 15:13:29 +1100 |
commit | 01695a9687e5a8d78589605037cc7828a5b67ac9 (patch) | |
tree | 3d7f4ed52b1bbaffd62e6d04aaefc2f5989e32e6 /init | |
parent | 6f29c3298b18216198631cbee01c349adecb225d (diff) | |
download | kernel_samsung_smdk4412-01695a9687e5a8d78589605037cc7828a5b67ac9.tar.gz kernel_samsung_smdk4412-01695a9687e5a8d78589605037cc7828a5b67ac9.tar.bz2 kernel_samsung_smdk4412-01695a9687e5a8d78589605037cc7828a5b67ac9.zip |
powerpc/32: Allow __ioremap on RAM addresses for kdump kernel
While for debugging it is good to catch bogus users of ioremap, though
for kdump support it is more convenient to use __ioremap for
copy_oldmem_page() (exactly as we do for PPC64 currently).
Note that copy_oldmem_page() calls __ioremap with flags set to '0',
so it should be safe with the regard to the caches.
The other option is to use kmap_atomic_pfn()[1], but it will not work
for kernels compiled without HIGHMEM.
That is, on a board with 256MB RAM and crashkernel=64M@32M case, the
!HIGHMEM capturing kernel maps 0-96M range, which does not include all
the memory needed to capture the dump. And, obviously, accessing
anything upper than 96M will cause faults.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046747.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions