Dave Anderson wrote:
David Wilder wrote:
> The definitions for page->flags in crash are no longer correct in crash
> resulting in incorrect output for the kmem -i command. The page flags
> are currently defined for V22 V24 and one flag for V26. The flag
> definitions are changing in the 2.6 kernel often, crash will need to
> update these definitions for each 2.6.x. Yuck! Can we limit the flag
> definitions to just a few kernel versions? Any suggestions on what
> versions we should have definitions for?
>
I've long since been keeping up with these, because most
of the hardwired page flag definitions that are #define'd
in memory.c are not used anymore. For example, there's
this construct in dump_mem_map() which just displays the
hex value:
if (v22) {
...translate hardwired flags...
} else if (THIS_KERNEL_VERSION > LINUX(2,4,9)) {
fprintf(fp, "%lx\n", flags);
} else {
...translate old hardwired 2.4 flags...
}
But there are a few other places that need to know about
specific flags, like PG_reserved and PG_slab for example,
whose bits get determined in vm_init(). Which one has
changed that upsets "kmem -i"?
Dave
I was first looking at PG_slab. But I now see this bit in vm_init()
if (VALID_MEMBER(page_pte)) {
if (THIS_KERNEL_VERSION < LINUX(2,6,0))
vt->PG_slab = 10;
else if (THIS_KERNEL_VERSION >= LINUX(2,6,0))
vt->PG_slab = 7;
}
This would set the correct value for vt->PG_slab = 7 except that pte is
not a member of the struct page so vt->PG_slab=0.
vt->PG_reserved is not getting set in PG_reserved_flag_init(). But that
looks like a problem resolving the symbol sys_read. So in
dump_mem_map() it is falling back to v24_PG_reserved....
case GET_TOTALRAM_PAGES:
if (vt->PG_reserved)
PG_reserved_flag = vt->PG_reserved;
else
PG_reserved_flag = v22 ?
1 << v22_PG_reserved :
1 << v24_PG_reserved;
....
That should mess up the calculation for total memory for kmem -i. But
in my case the number is still correct..
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder(a)us.ibm.com
(503)578-3789