----- Original Message -----
 
 
 ----- Original Message -----
 > ----- Original Message -----
 > >
 > > I'll take a look at these when I get the chance, but I'm really
 > > not particularly excited unless they are actual bugs.
 > 
 > Like this one:
 > 
 > --- a/memory.c
 > +++ b/memory.c
 > @@ -17003,8 +17003,8 @@ valid_section(ulong addr)
 >  
 >  	if ((mem_section = read_mem_section(addr)))
 >          	return (ULONG(mem_section +
 > -			OFFSET(mem_section_section_mem_map)) &&
 > -			SECTION_MARKED_PRESENT);
 > +			OFFSET(mem_section_section_mem_map))
 > +			& SECTION_MARKED_PRESENT);
 >  	return 0;
 >  }
 >  
 > @@ -17016,7 +17016,7 @@ section_has_mem_map(ulong addr)
 >  	if ((mem_section = read_mem_section(addr)))
 >  		return (ULONG(mem_section +
 >  			OFFSET(mem_section_section_mem_map))
 > -			&& SECTION_HAS_MEM_MAP);
 > +			& SECTION_HAS_MEM_MAP);
 >  	return 0;
 >  }
 > 
 > This code has been like this since the original CONFIG_SPARSEMEM support
 > patch was posted back in 2006.  Interesting that this has never been a
 > problem.  Apparently nobody's ever bumped into mem_section that didn't
 > have those flags.
 
 Interestingly enough, this patch breaks RHEL5 and earlier kernels.
 (try "kmem -n" with and without the patch).  Probably a flag issue with
 earlier CONFIG_SPARSEMEM kernels.
 
 Dave 
OK, mystery solved.  Prior to 2.6.24, the SECTION_HAS_MEM_MAP bit existed,
but it was never set/used in the mem_section.section_mem_map combination
pointer/bitmask.  So when run against the early kernels, the patched version
of section_has_mem_map() above would fail because only the SECTION_MARKED_PRESENT
bit was ever set.  
However, for all practical purposes, if a mem_section exists, it is valid, so 
even without the patch, things have always worked just fine with the coding
error in place.
Regardless, I fixed the patch to be based upon the kernel version, and queued
it for crash-7.1.2:
  
https://github.com/crash-utility/crash/commit/e81db08bc69fb1a7a7e48f892c2...
Dave