I am having the similar problem for PPC64 port. In I386,
min_low_pfn contains the page number of _pa(_end). Whereas in PPC64, it
will be assigned based on bootmem_bootmap_pages function and it could be
anywhere based on lmb_alloc (PPC64 related function). On my PPC64
machine, min_low_pfn is having like 520176 (total number of pages =
524288). Since the dump_low_page returns 1 for all pages less than 520176
+ 16 (in my case - bootmem pages) + 1024, dumping almost all pages in the
first pass itself. Hence, I think, we should change the dump_low_page
function such that it checks just bootmap pages as anyway the kernel
static pages are reserved. Therefore, we should still keep this function
in the arch independent code. Could you post your thoughts since I am not
sure how min_low_pfn is defined in IA64. - See below my dump_filters.c
Also, dump_calc_bootmap_pages function is getting called for every page in
the first pass even though it returns the constant value. We should call
this before start scanning all pages. (from dump_generic_execute function
before calling dump_execute_savedump)
In 2.6 LKCD, the arch specific dump_header related code is moved to arch
independent files (dump_fmt.c) and declared some variables
(dha_smp_current_task, dha_stack, dha_stack_ptr) as U32. I believe, these
should change to 'void *' to save 64 bit addresses. Please let me know
whether you moved this code back to arch dependent files.
Hello all, Let me know you comments/suggestions since the above change
will also effect i386 and ARM specific files.
--- 2.6/drivers/dump/dump_filters.c 2003-12-18 21:29:57.000000000
+++ ../linux-2.6.0-test9/drivers/dump/dump_filters.c 2003-12-18
@@ -27,31 +27,29 @@
+#define DUMP_PFN_SAFETY_MARGIN 1024 /* 4 MB */
+static unsigned long bootmap_pages;
/* Copied from mm/bootmem.c - FIXME */
/* return the number of _pages_ that will be allocated for the boot bitmap
-unsigned long dump_calc_bootmap_pages (void)
+void dump_calc_bootmap_pages (void)
unsigned long mapsize;
unsigned long pages = num_physpages;
mapsize = (pages+7)/8;
mapsize = (mapsize + ~PAGE_MASK) & PAGE_MASK;
mapsize >>= PAGE_SHIFT;
- return mapsize;
+ bootmap_pages = mapsize + DUMP_PFN_SAFETY_MARGIN + 1;
-#define DUMP_PFN_SAFETY_MARGIN 1024 /* 4 MB */
/* temporary */
extern unsigned long min_low_pfn;
int dump_low_page(struct page *p)
- return page_to_pfn(p) < min_low_pfn + dump_calc_bootmap_pages()
- + 1 + DUMP_PFN_SAFETY_MARGIN;
+ return ((page_to_pfn(p) >= min_low_pfn) &&
+ (page_to_pfn(p) < (min_low_pfn + bootmap_pages)));
static inline int kernel_page(struct page *p)
---------------------- Forwarded by Haren Myneni/Beaverton/IBM on 12/18/2003 09:37 PM ---------------------------
Please respond to suparna@...
Sent by: lkcd-devel-admin@...
To: Arvind Kandhare <arvind.kan@...>
cc: lkcd-devel <lkcd-devel@...>, Takao Indoh
Subject: [lkcd-devel] Re: [RFC]Filter code change for IA64
Could you post your complete patch for ia64, even if its still
WIP so we can see the whole flow (including the definition of
IS_PINNED_ADDRESS and the code that passes the phys addr to the
It would help make some things clearer to me, for example,
what prevents you from deriving the phys addr from the page frame
number you get via page_to_pfn (which should work for discontig mem
The LKCD logic is now structured to operate on physical page frames,
so the existence of virtual address mappings should not ideally have
affected the selection logic. So we need to understand what's going
on more closely. The dump_low_page() routine, of course
might have an arch specific component, but the detection of kernel
static pages is based on the assumption that they would be marked
as reserved. Is that assumption not valid in this case ?
On Wed, Dec 10, 2003 at 10:31:35AM +0530, Arvind Kandhare wrote:
> Suparna Bhattacharya wrote:
> >Hello Arvind,
> >It would be preferable to do this in a way that avoids platform
> >ifdefs in arch independent code bits.
> > Should we simply define an arch-specific version of dump_low_page
> Thanks for the feedback. We'll try and put it in the implementation for
> >Could you explain the intent of your changes ?
> We tried to use the same filters as IA32 and observed the following
> 1. The filters do not work. (i.e. all the pages are selected as filter
> 2. All the kernel static address pages (i.e. virtual address
> _start and _end)
> are not dumped properly.
> After further investigation and discussions with ia64 mailing list we
> that some of the kernel addresses are pinned in DTR TLB cache and they
> not have
> a page table entry(??).
> To find out such addresses we are checking the physical addresses
> to be translated with the TLB pinned address. This is the reason behind
> the physical address as one more parameter to the filter code.
> Please let us know whether our interpretation is correct and if there is
> way which we can make it more generalized and optimal.
> Thanks and regards,
> Confidentiality Notice
> The information contained in this electronic message and any attachments
> this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or
> Mailadmin@... immediately
> and destroy all copies of this message and any attachments.
Suparna Bhattacharya (suparna@...)
Linux Technology Center
IBM Software Lab, India
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
lkcd-devel mailing list