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