[Crash-utility] [PATCH] Support cpu_map/cpu_mask changes in 2.6.29 & module debuginfo search

Dave Anderson anderson at redhat.com
Wed Apr 29 18:04:29 UTC 2009


Hi Michael,

I made a few other changes to your cpu map/mask patch:

- cpu_map_size() has been changed to use the symbol-name-creation
   scheme as cpu_map_addr() in order to absolutely maintain the
   backwards-compatibility issue brought up by Robin.  So if the
   old symbol names still exist, the code does exactly the same
   thing that it used to.

- Your changes to get_cpus_present() and get_cpus_possible() were
   incomplete because they were still using the hardwired "cpus_present_map"
   and "cpus_possible_map" symbols.

- I didn't change the s390.c and s390x.c s390[x]_get_smp_cpus()
   functions beyond what you did, but I think they should be
   changed to use get_cpus_online() instead of the way they
   are doing it now.  As it is now, they are restricting themselves
   to the number of cpu bits in a per-arch long.  If the
   s390 CONFIG_NR_CPUS can exceed 32, or the s390x CONFIG_NR_CPUS
   can exceed 64, then those two functions are incorrect.
   If the architecture limits them to 32/64, then I suppose the
   way it's done now is OK.  That's your call...

Also, the attached patch contains the changes for searching
for kernel module debuginfo files in the same directory tree
specified with "mod -S <directory>".  Alternatively there
is a new "crash --mod <directory>" command line option, such
that "mod -S" with no directory argument will default to
searching the command-line specified directory.

Anyway, I've only tested this on older kernels that still have
the  "cpu_xxxx_map" symbols.  Can you test the patch on new
kernels?  And also let me know whether the s390[x] functions
should be updated.

Thanks,
   Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpu_maps_and_module_debuginfo.patch
Type: text/x-patch
Size: 19881 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20090429/4bc5bd77/attachment.bin>


More information about the Crash-utility mailing list