[Crash-utility] Reasons why kdump isn't activated

[Dave Anderson]

----- "Laurence A. Oberman" <online at photonlinux.com> wrote:

> Hi Dave
> 
> I use crash all the time on SLES dumps. I still have problems with the
> SLAB stuff, even with 5.0.
> 
> "crash: unable to initialize kmem slab cache subsystem"
> 
> Is there a fix for this or am I missing something in creating the
> debug vmlinux kernel
> 
> crash 5.0.0
> Copyright (C) 2002-2010  Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006  IBM Corporation
> Copyright (C) 1999-2006  Hewlett-Packard Co
> Copyright (C) 2005, 2006  Fujitsu Limited
> Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
> Copyright (C) 2005  NEC Corporation
> Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions.  Enter "help copying" to see the conditions.
> This program has absolutely no warranty.  Enter "help warranty" for
> details.
> 
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
> 
> WARNING: could not find MAGIC_START!
> please wait... (gathering kmem slab cache data)\
> crash: seek error: kernel virtual address: 1082fffea00  type: "kmem_cache buffer" ---->
> 
> crash: unable to initialize kmem slab cache subsystem
> 
>   SYSTEM MAP: map.0
> DEBUG KERNEL: vmlinux (2.6.5-7.244-smp)
>     DUMPFILE: dump.0
>         CPUS: 4
>         DATE: Sat Feb  6 12:43:37 2010
>       UPTIME: 213503982289 days, 20:38:24
> LOAD AVERAGE: 260.75, 259.77, 258.95
>        TASKS: 1167
>     NODENAME: linuscs73
>      RELEASE: 2.6.5-7.252-smp
>      VERSION: #2 SMP Mon Jun 22 13:11:57 PDT 2009
>      MACHINE: x86_64  (2666 Mhz)
>       MEMORY: 32.7 GB
>        PANIC: "manual"
>          PID: 8741
>      COMMAND: "lkcd_config"
>         TASK: 107ed5d6b40  [THREAD_INFO: 1024f3ac000]
>          CPU: 2
>        STATE: TASK_RUNNING (PANIC)
>  
> 
> Thanks
> Laurence

The "seek error" indicates that the kmem slab page associated with
virtual address 1082fffea00, which is unity-mapped to physical 
address 82fffea00, could not be found in the dump.0 file.

If we presume that it is a "correct" address, physical address
82fffea00 is *very* close to the end of physical memory on that
system, which shows "32.7 GB".  If you enter:

  crash> kmem -p | tail

and wait a while because of the size of the dump, it will eventually
dump the end of the system's mem_map array of physical pages, where
the second column in the list contains the physical address.

I only have one SLES9 (2.6.5-7.315-smp) dumpfile example, which is
a 16GB dumpfile, and the output looks like this:

  crash> kmem -p | tail
  10407efdd98      407ff5000                0        0  0 d000080
  10407efddd0      407ff6000                0        0  0 d000080
  10407efde08      407ff7000                0        0  0 d000080
  10407efde40      407ff8000                0        0  0 d000080
  10407efde78      407ff9000                0        0  0 d000080
  10407efdeb0      407ffa000                0        0  0 d000080
  10407efdee8      407ffb000                0        0  0 d000080
  10407efdf20      407ffc000                0        0  0 d000080
  10407efdf58      407ffd000                0        0  0 d000080
  10407efdf90      407ffe000                0        0  0 d000080
  crash>

where 407ffe000 is the last page of physical memory on the system.

If you do the same thing, how does the last physical page compare
to 82fffea00?

Dave

 

output looks like this