[Crash-utility] Reasons why kmem slab cache mapping does not work on SLES 9 and lkcd dump

[Laurence A. Oberman]

Hi Dave,

Thanks, yes it is a 32GB configuration.

Based on my dump here, (which was a kernel pages only dump),it is indeed missing that memory address at the end of the list. The last address is 82fffe000.

I forced the dump for DLM lock problem which I understand and was able to research, but the SLAB stuff has never worked for me on SLES 9.

This may just be a bug with lkcd. I never have these problems on Redhat with kdump.

I will test it on a SLES 11 running kdump and see what happens


crash> kmem -p | tail
1001da7fd98      82fff5000                0        0  0 1000080
1001da7fdd0      82fff6000                0        0  0 1000080
1001da7fe08      82fff7000                0        0  0 1000080
1001da7fe40      82fff8000                0        0  0 1000080
1001da7fe78      82fff9000                0        0  0 1000080
1001da7feb0      82fffa000                0        0  0 1000080
1001da7fee8      82fffb000                0        0  0 1000080
1001da7ff20      82fffc000                0        0  0 1000080
1001da7ff58      82fffd000                0        0  0 1000080
1001da7ff90      82fffe000                0        0  0 1000080
 
crash> sys
  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"
crash> 
                                                         
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

 


--
Crash-utility mailing list
Crash-utility at redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility