----- Original Message -----
> > In order to understand this error better I took a look at
> > diskdump.c:read_diskdump():
> >
> > if (!page_is_dumpable(pfn)) {
> > if ((dd->flags & (ZERO_EXCLUDED|ERROR_EXCLUDED)) ==
> > ERROR_EXCLUDED) {
> > if (CRASHDEBUG(8))
> > fprintf(fp, "read_diskdump: PAGE_EXCLUDED: "
> > "paddr/pfn: %llx/%lx\n",
> > (ulonglong)paddr, pfn);
> > return PAGE_EXCLUDED;
> > }
> > if (CRASHDEBUG(8))
> > fprintf(fp, "read_diskdump: zero-fill: "
> > "paddr/pfn: %llx/%lx\n",
> > (ulonglong)paddr, pfn);
> > memset(bufptr, 0, cnt);
> > return cnt;
> > }
> >
> > Does this mean these kernel pages are *not* zero?
>
> No, it means that if you invoke crash with the --zero_excluded flag,
> if an excluded page is encountered during runtime, it will return
> a zero-filled page instead of erroring out.
Stefan,
Sorry -- I misunderstood the question, and my response is irrelevant/misleading.
The answer to the question is actually: not necessarily...
Here's why:
The compressed kdump dumpfile header contains a per-page bitmap
for the crashed kernel's maximum memory size:
- If a page's bit is set to 1, then that page also has a small
page descriptor structure, which in turn points to the page's
contents in the dumpfile.
- If a page's bit is set to 0, the page is excluded. If an attempt
is made to read the page, page_is_dumpable() will return FALSE,
and the command will fail with an error message that indicates:
"<command>: page excluded: <memory type> <address> ..."
When a compressed kdump has been filtered based upon the
"makedumpfile -d <dump_level>" setting, these 5 page types
may be configured:
#define DL_EXCLUDE_ZERO (0x001) /* Exclude Pages filled with Zeros */
#define DL_EXCLUDE_CACHE (0x002) /* Exclude Cache Pages without Private Pages */
#define DL_EXCLUDE_CACHE_PRI (0x004) /* Exclude Cache Pages with Private Pages */
#define DL_EXCLUDE_USER_DATA (0x008) /* Exclude UserProcessData Pages */
#define DL_EXCLUDE_FREE (0x010) /* Exclude Free Pages */
When makedumpfile does the filtering, it first checks the configuration
of the DL_EXCLUDE_CACHE, DL_EXCLUDE_CACHE_PRI, DL_EXCLUDE_USER_DATA
and DL_EXCLUDE_FREE settings, the relevant pages will not be copied
to the dumpfile, and so their bitmap bits will be set to 0.
After the 4 DL_EXCLUDE_xxx pages above have been filtered, the DL_EXCLUDE_ZERO
configuration is handled, and the remaining pages will be checked whether
they are zero-filled. If so, their bitmap bits will be set to 1, but
their page descriptors will all point to single, common, zero-filled
page in the dumpfile.
So getting back to the question:
> > Does this mean these kernel pages are *not* zero?
The reason the answer is "not necessarily" is because it is highly
likely that a zero-filled page may have been pre-filtered by one of the
other DL_EXCLUDE_xxx bits, and therefore it would have been excluded
prior to the subsequent DL_EXCLUDE_ZERO check.
And again, the --zero_excluded flag allows a crash user to prevent
a command from failing due to an excluded page. But the result of
doing so is also completely unpredictable, so it should only be used
with care and understanding...
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
