dev -p command fails post linux 2.6.25
by Sharyathi Nagesh
Hi Dave
As you may be aware dev -p command post linux kernel 2.6.25 fails with
"no PCI devices found on this system.". When I went through the kernel
a specific commit has removed pci_devices variable from the kernel code
==================================================================
git commit: 5ff580c10ec06fd296bd23d4570c1a95194094a0
by Greg Kroah-Hartman <gregkh(a)suse.de>
This is what he says in the commit
------------------------------------------------------------------------------------------------------------
This patch finally removes the global list of PCI devices. We are
relying entirely on the list held in the driver core now, and do not
need a separate "shadow" list as no one uses it.
------------------------------------------------------------------------------------------------------------
==================================================================
I saw some of your earlier postings where you have specifically
mentioned about this problem:
http://www.mail-archive.com/crash-utility@redhat.com/msg00346.html
With this I wanted to know, if you intend to keep dev -p behavior as it
is now or
there is any plan to change it to display actual values?
Thank You
Sharyathi N
15 years
Re: [Crash-utility] crash seek error, failed to read vmcore file
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> >
> > In any case, unfortunately, there's nothing can be done from the crash
> > utility's perspective.
> >
> > Dave
>
> Thank you Dave.
>
> Our SLES11 does not have the above patch you mentioned, but at the same
> time system is not AMS enabled and CONFIG_CMM is also not set in the config file..
>
> This system also has /proc/device-tree/memory@0 dir only..
I don't have access to the original "problem" ppc64 machine,
but here I'm logged into another ppc64, where the memory
advertised in /proc/device-tree is as expected. It has
these file memory@xxx/reg files, showing a set of contiguous
memory chunks. The first one is 128MB, followed by a series
of 16MB chunks:
memory@0: 0000000000000000 0000000008000000
memory@8000000: 0000000008000000 0000000001000000
memory@9000000: 0000000009000000 0000000001000000
memory@a000000: 000000000a000000 0000000001000000
memory@b000000: 000000000b000000 0000000001000000
memory@c000000: 000000000c000000 0000000001000000
memory@d000000: 000000000d000000 0000000001000000
memory@e000000: 000000000e000000 0000000001000000
memory@f000000: 000000000f000000 0000000001000000
memory@10000000: 0000000010000000 0000000001000000
memory@11000000: 0000000011000000 0000000001000000
memory@12000000: 0000000012000000 0000000001000000
memory@13000000: 0000000013000000 0000000001000000
memory@14000000: 0000000014000000 0000000001000000
memory@15000000: 0000000015000000 0000000001000000
memory@16000000: 0000000016000000 0000000001000000
memory@17000000: 0000000017000000 0000000001000000
memory@18000000: 0000000018000000 0000000001000000
memory@19000000: 0000000019000000 0000000001000000
memory@1a000000: 000000001a000000 0000000001000000
memory@1b000000: 000000001b000000 0000000001000000
memory@1c000000: 000000001c000000 0000000001000000
memory@1d000000: 000000001d000000 0000000001000000
memory@1e000000: 000000001e000000 0000000001000000
memory@1f000000: 000000001f000000 0000000001000000
memory@20000000: 0000000020000000 0000000001000000
memory@21000000: 0000000021000000 0000000001000000
memory@22000000: 0000000022000000 0000000001000000
memory@23000000: 0000000023000000 0000000001000000
memory@24000000: 0000000024000000 0000000001000000
memory@25000000: 0000000025000000 0000000001000000
memory@26000000: 0000000026000000 0000000001000000
memory@27000000: 0000000027000000 0000000001000000
memory@28000000: 0000000028000000 0000000001000000
memory@29000000: 0000000029000000 0000000001000000
memory@2a000000: 000000002a000000 0000000001000000
memory@2b000000: 000000002b000000 0000000001000000
memory@2c000000: 000000002c000000 0000000001000000
memory@2d000000: 000000002d000000 0000000001000000
memory@2e000000: 000000002e000000 0000000001000000
memory@2f000000: 000000002f000000 0000000001000000
memory@30000000: 0000000030000000 0000000001000000
memory@31000000: 0000000031000000 0000000001000000
memory@32000000: 0000000032000000 0000000001000000
memory@33000000: 0000000033000000 0000000001000000
memory@34000000: 0000000034000000 0000000001000000
memory@35000000: 0000000035000000 0000000001000000
memory@36000000: 0000000036000000 0000000001000000
memory@37000000: 0000000037000000 0000000001000000
memory@38000000: 0000000038000000 0000000001000000
memory@39000000: 0000000039000000 0000000001000000
memory@3a000000: 000000003a000000 0000000001000000
memory@3b000000: 000000003b000000 0000000001000000
memory@3c000000: 000000003c000000 0000000001000000
memory@3d000000: 000000003d000000 0000000001000000
memory@3e000000: 000000003e000000 0000000001000000
memory@3f000000: 000000003f000000 0000000001000000
memory@40000000: 0000000040000000 0000000001000000
memory@41000000: 0000000041000000 0000000001000000
memory@42000000: 0000000042000000 0000000001000000
memory@43000000: 0000000043000000 0000000001000000
memory@44000000: 0000000044000000 0000000001000000
memory@45000000: 0000000045000000 0000000001000000
memory@46000000: 0000000046000000 0000000001000000
memory@47000000: 0000000047000000 0000000001000000
memory@48000000: 0000000048000000 0000000001000000
memory@49000000: 0000000049000000 0000000001000000
memory@4a000000: 000000004a000000 0000000001000000
memory@4b000000: 000000004b000000 0000000001000000
memory@4c000000: 000000004c000000 0000000001000000
memory@4d000000: 000000004d000000 0000000001000000
memory@4e000000: 000000004e000000 0000000001000000
memory@4f000000: 000000004f000000 0000000001000000
memory@50000000: 0000000050000000 0000000001000000
memory@51000000: 0000000051000000 0000000001000000
memory@52000000: 0000000052000000 0000000001000000
memory@53000000: 0000000053000000 0000000001000000
memory@54000000: 0000000054000000 0000000001000000
memory@55000000: 0000000055000000 0000000001000000
memory@56000000: 0000000056000000 0000000001000000
memory@57000000: 0000000057000000 0000000001000000
memory@58000000: 0000000058000000 0000000001000000
memory@59000000: 0000000059000000 0000000001000000
memory@5a000000: 000000005a000000 0000000001000000
memory@5b000000: 000000005b000000 0000000001000000
memory@5c000000: 000000005c000000 0000000001000000
memory@5d000000: 000000005d000000 0000000001000000
memory@5e000000: 000000005e000000 0000000001000000
memory@5f000000: 000000005f000000 0000000001000000
memory@60000000: 0000000060000000 0000000001000000
memory@61000000: 0000000061000000 0000000001000000
memory@62000000: 0000000062000000 0000000001000000
memory@63000000: 0000000063000000 0000000001000000
memory@64000000: 0000000064000000 0000000001000000
memory@65000000: 0000000065000000 0000000001000000
memory@66000000: 0000000066000000 0000000001000000
memory@67000000: 0000000067000000 0000000001000000
memory@68000000: 0000000068000000 0000000001000000
memory@69000000: 0000000069000000 0000000001000000
memory@6a000000: 000000006a000000 0000000001000000
memory@6b000000: 000000006b000000 0000000001000000
memory@6c000000: 000000006c000000 0000000001000000
memory@6d000000: 000000006d000000 0000000001000000
memory@6e000000: 000000006e000000 0000000001000000
memory@6f000000: 000000006f000000 0000000001000000
memory@70000000: 0000000070000000 0000000001000000
memory@71000000: 0000000071000000 0000000001000000
memory@72000000: 0000000072000000 0000000001000000
memory@73000000: 0000000073000000 0000000001000000
memory@74000000: 0000000074000000 0000000001000000
memory@75000000: 0000000075000000 0000000001000000
memory@76000000: 0000000076000000 0000000001000000
memory@77000000: 0000000077000000 0000000001000000
memory@78000000: 0000000078000000 0000000001000000
memory@79000000: 0000000079000000 0000000001000000
memory@7a000000: 000000007a000000 0000000001000000
memory@7b000000: 000000007b000000 0000000001000000
So the end of physical memory is at 7b000000 + 1000000, which
I can verify by running crash on the live system:
crash> eval 7b000000 + 0x1000000
hexadecimal: 7c000000 (1984MB)
decimal: 2080374784
octal: 17400000000
binary: 0000000000000000000000000000000001111100000000000000000000000000
crash> eval 7c000000 / 64k
hexadecimal: 7c00 (31KB)
decimal: 31744
octal: 76000
binary: 0000000000000000000000000000000000000000000000000111110000000000
crash> p num_physpages
num_physpages = $9 = 31744
crash>
and which matches what's in the kernel memory zone data:
crash> kmem -n
NODE SIZE PGLIST_DATA BOOTMEM_DATA NODE_ZONES
0 31744 c00000007bfdf280 c000000000a53c50 c00000007bfdf280
c00000007bfe1900
c00000007bfe3f80
MEM_MAP START_PADDR START_MAPNR
f000000000000000 0 0
ZONE NAME SIZE MEM_MAP START_PADDR START_MAPNR
0 DMA 31744 f000000000000000 0 0
1 Normal 0 0 0 0
2 Movable 0 0 0 0
...
So everything looks fine.
But if your system has just a single /proc/device-tree/memory@0
directory whose size doesn't match up with what the live kernel is
using, then that's the kernel bug.
> In any case, unfortunately, there's nothing can be done from the crash
> utility's perspective.
BTW, you can get minimal data from your truncated vmcore using
the --minimal switch that IBM contributed a while back:
# crash --minimal vmcore vmlinux
It at least offers the log, dis, rd, sym and eval commands, which may
or may not help. It's actually come in quite handy a few times.
Anyway, if you guys come up with a kernel fix, can you post it here
as well?
Thanks,
Dave
15 years
Re: [Crash-utility] crash seek error, failed to read vmcore file
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> On Tue, 2010-04-20 at 09:14 -0400, Dave Anderson wrote:
> > ----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> >
> > The cause for seek errors depends upon the type
> > of dumpfile.
> >
> > You didn't mention which type of dumpfile the vmcore
> > is, so I'll presume that it's either an ELF-format
> > kdump or a compressed kdump created by makedumpfile.
> >
> > So presuming that it's a compressed kdump, the seek error
> > most likely comes from here in read_diskdump() in diskdump.c:
> >
> > if ((pfn >= dd->header->max_mapnr) || !page_is_ram(pfn))
> > return SEEK_ERROR;
> >
> > where the requested physical address pfn values are larger
> > than the max_mapnr value advertised in the header.
> >
> > When you do any "crash -d# ...", the dumpfile header will
> > be dumped first. What does that show?
> >
> > Dave
>
>
> Dave,
>
> Dumpfile is compressed kdump created by makedumpfile.
>
> header shows the following values:
> max_mapnr: 32768
> block_shift: 16
>
> Yes. Adding some debug printf's shows me that (pfn >=
> dd->header->max_mapnr) fails.
>
> For example: in the first seek error,
> crash: seek error: kernel virtual address: c0000000af715480 type:
> "kmem_cache buffer"
>
> paddr: af715480 => pfn=44913
>
> crash -d8 log: http://pastebin.com/qrCvyPfR
>
> Thanks..Pavan
OK, so the compressed dumpfile has exactly 32768 pages of physical
memory, or exactly 2GB. That being the case, the crash utility
will fail all readmem attempts above that value, and obviously
there is critical data above the artificial 2GB threshold.
The question at hand is why kdump is creating a truncated dumpfile
with a max_mapnr of 32768:
(1) makedumpfile determines the "max_mapnr" value based upon the
highest physical address found in any of the PT_LOAD segments
of the /proc/vmcore file on the secondary kernel.
(2) the /proc/vmcore PT_LOAD segments were pre-calculated during
the primary kernel's kdump initialization phase, based upon
the values found in the set of "/proc/device-tree/memory@xxx/reg"
files existing in the primary kernel, where the "xxx" is the
starting physical address of the memory region, and the "reg"
file in that directory contains the size of the memory region.
For whatever reason, those files showed a maximum of 2GB of
physical memory. (If you do not use makedumpfile, and then do
a "readelf -a" of the resultant vmcore file, you will see
the PT_LOAD segment values.)
Does the SLES11 vmlinux-2.6.32.10-0.4.99.25.62005-ppc64 kernel
contain this patch?:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.gi...
author Brian King <brking(a)linux.vnet.ibm.com>
Mon, 19 Oct 2009 05:51:34 +0000 (05:51 +0000)
committer Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Fri, 30 Oct 2009 06:20:56 +0000 (17:20 +1100)
commit 8be8cf5b47f72096e42bf88cc3afff7a942a346c
tree 9adff0fa02123f48fbfa40abb55a5c01be8c2fa4
parent 6cff46f4bc6cc4a8a4154b0b6a2e669db08e8fd2
powerpc: Add kdump support to Collaborative Memory Manager
When running Active Memory Sharing, the Collaborative Memory Manager (CMM)
may mark some pages as "loaned" with the hypervisor. Periodically, the
CMM will query the hypervisor for a loan request, which is a single signed
value. When kexec'ing into a kdump kernel, the CMM driver in the kdump
kernel is not aware of the pages the previous kernel had marked as "loaned",
so the hypervisor and the CMM driver are out of sync. Fix the CMM driver
to handle this scenario by ignoring requests to decrease the number of loaned
pages if we don't think we have any pages loaned. Pages that are marked as
"loaned" which are not in the balloon will automatically get switched to "active"
the next time we touch the page. This also fixes the case where totalram_pages
is smaller than min_mem_mb, which can occur during kdump.
Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
I ask because we also have an outstanding bugzilla that exhibits similar
behavior, where an abnormally small ppc64 vmcore file gets created
because there was only a single /proc/device-tree/memory@0 directory
file that showed just a small subset of the total physical memory.
Typically there are many of those "memory@xxx" directories, but in
the failing scenario, there was only one /proc/device-tree/memory@0
directory.
Anyway, there's (unproven) speculation that the kernel patch above
is related to the problem.
In any case, unfortunately, there's nothing can be done from the crash
utility's perspective.
Dave
15 years
Re: [Crash-utility] crash seek error, failed to read vmcore file
by Dave Anderson
----- "Pavan Naregundi" <pavan(a)linux.vnet.ibm.com> wrote:
> Hi Everyone,
>
> We are facing a problem while analysing the vmcore on PPC64 systems
> running SLES11 SP1.
>
> ===============
> please wait... (gathering kmem slab cache data)
>
> crash: seek error: kernel virtual address: c0000000af715480 type: "kmem_cache buffer"
>
> crash: unable to initialize kmem slab cache subsystem
>
> please wait... (gathering module symbol data)
> WARNING: cannot access vmalloc'd module memory
>
> please wait... (gathering task table data)
> crash: cannot read pid_hash upid
>
> crash: cannot read pid_hash upid
>
> crash: cannot read pid_hash upid
> =====================
>
> Version: crash-5.0.3
>
> Command used:
> #crash vmlinux-2.6.32.10-0.4.99.25.62005-ppc64.debug
> vmlinux-2.6.32.10-0.4.99.25.62005-ppc64 vmcore
>
> Attaching the output of the above command..
>
>
> Using crash -d8 for above command,
> ========================
> <snip>
> <readmem: c00000000134ffa0, KVADDR, "memory section", 32, (FOE), 122f94b0>
> addr: c00000000134ffa0 paddr: 134ffa0 cnt: 32
> <readmem: c00000000134ffc0, KVADDR, "memory section", 32, (FOE), 122f94b0>
> addr: c00000000134ffc0 paddr: 134ffc0 cnt: 32
> <readmem: c00000000134ffe0, KVADDR, "memory section", 32, (FOE), 122f94b0>
> addr: c00000000134ffe0 paddr: 134ffe0 cnt: 32
> NOTE: page_hash_table does not exist in this kernel
>
> please wait... (gathering kmem slab cache data)
> <readmem: c0000000012fc718, KVADDR, "cache_chain", 8, (FOE), fffeff7f108>
> addr: c0000000012fc718 paddr: 12fc718 cnt: 8
> GETBUF(248 -> 1)
> FREEBUF(1)
> GETBUF(10344 -> 1)
> <readmem: c000000000d8af90, KVADDR, "kmem_cache buffer", 10344, (FOE), 1082f5d8>
> addr: c000000000d8af90 paddr: d8af90 cnt: 10344
> GETBUF(248 -> 2)
> FREEBUF(2)
> FREEBUF(1)
> GETBUF(10344 -> 1)
> <readmem: c0000000af715480, KVADDR, "kmem_cache buffer", 10344, (ROE), 1082f5d8>
> addr: c0000000af715480 paddr: af715480 cnt: 10344
>
> crash: seek error: kernel virtual address: c0000000af715480 type: "kmem_cache buffer"
> FREEBUF(1)
>
> crash: unable to initialize kmem slab cache subsystem
> =================================
>
> NOTE: Crash was able to read a vmcore on the same system that was
> manually generated using: echo c > /proc/sysrq-trigger.
The cause for seek errors depends upon the type
of dumpfile.
You didn't mention which type of dumpfile the vmcore
is, so I'll presume that it's either an ELF-format
kdump or a compressed kdump created by makedumpfile.
If it's an ELF-format kdump, seek errors are returned
by the read_netdump() function in netdump.c. If the
ELF header indicates that the physical address is contained
within one of the PT_LOAD segments, it calculates the
vmcore file offset from that, and simply does this:
if (lseek(nd->ndfd, offset, SEEK_SET) == -1)
return SEEK_ERROR;
But that's highly unlikely to fail, even if the lseek
offset is beyond the end of the file. And if it went
beyond the end of the vmcore file, the subsequent read()
would fail, and return a READ_ERROR instead. Also, if
none of the ELF header PT_LOAD segments contain the requested
physical address, it also would have returned a READ_ERROR.
So presuming that it's a compressed kdump, the seek error
most likely comes from here in read_diskdump() in diskdump.c:
if ((pfn >= dd->header->max_mapnr) || !page_is_ram(pfn))
return SEEK_ERROR;
where the requested physical address pfn values are larger
than the max_mapnr value advertised in the header.
When you do any "crash -d# ...", the dumpfile header will
be dumped first. What does that show?
Dave
15 years
crash seek error, failed to read vmcore file
by Pavan Naregundi
Hi Everyone,
We are facing a problem while analysing the vmcore on PPC64 systems
running SLES11 SP1.
===============
please wait... (gathering kmem slab cache data)
crash: seek error: kernel virtual address: c0000000af715480 type:
"kmem_cache buffer"
crash: unable to initialize kmem slab cache subsystem
please wait... (gathering module symbol data)
WARNING: cannot access vmalloc'd module memory
please wait... (gathering task table data)
crash: cannot read pid_hash upid
crash: cannot read pid_hash upid
crash: cannot read pid_hash upid
=====================
Version: crash-5.0.3
Command used:
#crash vmlinux-2.6.32.10-0.4.99.25.62005-ppc64.debug
vmlinux-2.6.32.10-0.4.99.25.62005-ppc64 vmcore
Attaching the output of the above command..
Using crash -d8 for above command,
========================
<snip>
<readmem: c00000000134ffa0, KVADDR, "memory section", 32, (FOE),
122f94b0>
addr: c00000000134ffa0 paddr: 134ffa0 cnt: 32
<readmem: c00000000134ffc0, KVADDR, "memory section", 32, (FOE),
122f94b0>
addr: c00000000134ffc0 paddr: 134ffc0 cnt: 32
<readmem: c00000000134ffe0, KVADDR, "memory section", 32, (FOE),
122f94b0>
addr: c00000000134ffe0 paddr: 134ffe0 cnt: 32
NOTE: page_hash_table does not exist in this kernel
please wait... (gathering kmem slab cache data)<readmem:
c0000000012fc718, KVADDR, "cache_chain", 8, (FOE), fffeff7f108>
addr: c0000000012fc718 paddr: 12fc718 cnt: 8
GETBUF(248 -> 1)
FREEBUF(1)
GETBUF(10344 -> 1)
<readmem: c000000000d8af90, KVADDR, "kmem_cache buffer", 10344, (FOE),
1082f5d8>
addr: c000000000d8af90 paddr: d8af90 cnt: 10344
GETBUF(248 -> 2)
FREEBUF(2)
FREEBUF(1)
GETBUF(10344 -> 1)
<readmem: c0000000af715480, KVADDR, "kmem_cache buffer", 10344, (ROE),
1082f5d8>
addr: c0000000af715480 paddr: af715480 cnt: 10344
crash: seek error: kernel virtual address: c0000000af715480 type:
"kmem_cache buffer"
FREEBUF(1)
crash: unable to initialize kmem slab cache subsystem
=================================
NOTE: Crash was able to read a vmcore on the same system that was
manually generated using: echo c > /proc/sysrq-trigger.
Thanks..
Pavan
15 years
[ANNOUNCE] crash version 5.0.3 is available
by Dave Anderson
- Fix for running against 2.6.34 and later kernels to recognize and
handle changes in the kernel's per-cpu data symbol naming, which
no longer prefixes "per_cpu__" to declared per-cpu symbol names.
Without the patch, an x86_64 crash session fails completely during
initialization with the error message "crash: cannot determine idle
task addresses from init_tasks[] or runqueues[]", followed by "crash:
cannot resolve init_task_union"; on architectures such as the x86,
the session comes up to the "crash>" prompt, but displays warning
messages such as "WARNING: duplicate idle tasks?", the "swapper"
tasks are not found, and any command accessing per-cpu data fails.
(anderson(a)redhat.com)
- Fix for "swap" and "kmem -i" commands on 2.6.29 or later, big-endian,
ppc64 kernels, where the swap_info_struct.flags member was changed
from an int to a long. Without the patch, the "swap" command does
not display any swap data, and the "kmem -i" command indicates that
there is no swap memory used or available.
(anderson(a)redhat.com)
- Fix for the "vm" and "ps" command's task RSS value on 2.6.34 or later
kernels. Without the patch, the RSS value would always show "0k" or
"0" respectively, due to the replacement of the mm_struct._anon_rss
and mm_struct._file_rss counters with the mm_struct.rss_stat member.
(anderson(a)redhat.com)
- Fixed "possible aternatives" spelling typo used in informational
messages when an incorrect/unknown symbol name is used in "rd",
"dis", "sym" and "struct" commands.
(anderson(a)redhat.com)
- Fix for CONFIG_SPARSEMEM kernels that are not configured with
CONFIG_SPARSEMEM_EXTREME. Without the patch, "kmem -n" would show
faulty/missing sparsemem memmap data, and as a result, commands
requiring verification of page structure addresses contained within
the "missing" memmap sections would fail or show questionable data.
(nishimura(a)mxp.nes.nec.co.jp, anderson(a)redhat.com)
- Change the output of the "kmem -[cC]" options to indicate that they
are not supported when that is relevant. "kmem -c" has been obsolete
since 2.6.17, and "kmem -C" has been obsolete in all 2.6 era kernels.
(anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
15 years, 1 month
Re: [Crash-utility] [PATCH]Fixing swap command
by Dave Anderson
----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com> wrote:
> Description
> Sub-command "swap" in crash command doesn't show any info about swap
> partition in kernel versions 2.6.28 and above
>
> crash> swap
> FILENAME TYPE SIZE USED PCT PRIORITY
> crash> q
> feastlp4:~ #
Yes, I was already aware of that issue (big-endian only), and have a
patch queued for 5.0.3:
- Fix for "swap" and "kmem -i" commands on 2.6.29 or later, big-endian,
ppc64 kernels, where the swap_info_struct.flags member was changed
from an int to a long. Without the patch, the "swap" command does
not display any swap data, and the "kmem -i" command indicates that
there is no swap memory used or available.
(anderson(a)redhat.com)
Thanks,
Dave
15 years, 1 month
[PATCH]Fixing swap command
by Sharyathi Nagesh
Description
Sub-command "swap" in crash command doesn't show any info about swap
partition in kernel versions 2.6.28 and above
crash> swap
FILENAME TYPE SIZE USED PCT PRIORITY
crash> q
feastlp4:~ #
Analysis
Swap specific information comes from the kernel data structure
swap_info_struct
.The problem starts when it access the fields of swap_info_struct.
In this case
----------------------
flags = INT(vt->swap_info_struct +
OFFSET(swap_info_struct_flags));
if (!(flags & SWP_USED))
continue; <== Hits this case
----------------------
flags gets value '0' and hence it returns with out calculating swap values
This is happening because post 2.6.28 (precisely commit:
ebebbbe904634b0ca1c674457b399f68db5e05b1) changes flag field in
swap_info_struct from 'int' to 'unsigned long'. flags always gets zero
and jumps further calculation.
Fix
Patch has been attached to this mail
Thanks
Sharyathi
15 years, 1 month
[crash][patch] handle !SPARSEMEM_EX properly
by Daisuke Nishimura
In !SPARSEMEM_EX case, the symbol mem_section points a array of struct mem_section,
doesn't point a array of pointer to mem_section[], so I think the check:
if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
!IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
return 0;
in nr_to_section() is not a valid check in this case.
To make the matters worse, if CONFIG_CGROUP_MEM_RES_CTLR is enabled, the end of
struct mem_section is padded with 0.
So, reading mem_section by "rd" will look like:
crash> rd mem_section 128
c08b71e0: c9002003 c9001200 f7000000 00000000 . ..............
c08b71f0: c9002003 c9001260 f6980000 00000000 . ..`...........
c08b7200: c9002003 c90012c0 f6300000 00000000 . ........0.....
c08b7210: c9002003 c9001320 f5c80000 00000000 . .. ...........
...
This means nr_to_section() will return 0 when "nr" is 3,7,11,... because it meets
the condition(mem_sec[SECTION_NR_TO_ROOT(nr)] == mem_sec[nr] == 0).
As a result, mem_map for section 3,7,11,... cannot be handled properly.
Actually, "kmem -n" doesn't show a mem_map for them.
crash> kmem -n
...
NR SECTION CODED_MEM_MAP MEM_MAP PFN
0 c08b71e0 c9002000 c9002000 0
1 c08b71f0 c9002000 c9402000 131072
2 c08b7200 c9002000 c9802000 262144
4 c08b7220 c9002000 ca002000 524288
5 c08b7230 c9002000 ca402000 655360
6 c08b7240 c9002000 ca802000 786432
8 c08b7260 c8c02000 cac02000 1048576
9 c08b7270 c8c02000 cb002000 1179648
10 c08b7280 c8c02000 cb402000 1310720
12 c08b72a0 c8c02000 cbc02000 1572864
...
This patch is a fix for this problem. nr_to_section() will check "addr" by
IS_KVADDR() later anyway, so this patch just removes the problematic check.
Signed-off-by: Daisuke Nishimura <nishimura(a)mxp.nes.nec.co.jp>
---
diff -uprN crash-5.0.2.orig/memory.c crash-5.0.2/memory.c
--- crash-5.0.2.orig/memory.c 2010-04-05 16:08:52.000000000 +0900
+++ crash-5.0.2/memory.c 2010-04-06 09:56:43.000000000 +0900
@@ -13030,10 +13030,6 @@ nr_to_section(ulong nr)
}
}
- if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
- !IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
- return 0;
-
if (IS_SPARSEMEM_EX())
addr = mem_sec[SECTION_NR_TO_ROOT(nr)] +
(nr & SECTION_ROOT_MASK()) * SIZE(mem_section);
15 years, 1 month
Re: [Crash-utility] [crash][patch] handle !SPARSEMEM_EX properly
by Dave Anderson
----- "Daisuke Nishimura" <nishimura(a)mxp.nes.nec.co.jp> wrote:
> In !SPARSEMEM_EX case, the symbol mem_section points a array of struct mem_section,
> doesn't point a array of pointer to mem_section[], so I think the
> check:
>
> if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
> !IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
> return 0;
>
> in nr_to_section() is not a valid check in this case.
>
> To make the matters worse, if CONFIG_CGROUP_MEM_RES_CTLR is enabled, the end of
> struct mem_section is padded with 0.
>
> So, reading mem_section by "rd" will look like:
>
> crash> rd mem_section 128
> c08b71e0: c9002003 c9001200 f7000000 00000000 . ..............
> c08b71f0: c9002003 c9001260 f6980000 00000000 . ..`...........
> c08b7200: c9002003 c90012c0 f6300000 00000000 . ........0.....
> c08b7210: c9002003 c9001320 f5c80000 00000000 . .. ...........
> ...
>
> This means nr_to_section() will return 0 when "nr" is 3,7,11,... because it meets
> the condition(mem_sec[SECTION_NR_TO_ROOT(nr)] == mem_sec[nr] == 0).
>
> As a result, mem_map for section 3,7,11,... cannot be handled properly.
> Actually, "kmem -n" doesn't show a mem_map for them.
>
> crash> kmem -n
> ...
> NR SECTION CODED_MEM_MAP MEM_MAP PFN
> 0 c08b71e0 c9002000 c9002000 0
> 1 c08b71f0 c9002000 c9402000 131072
> 2 c08b7200 c9002000 c9802000 262144
> 4 c08b7220 c9002000 ca002000 524288
> 5 c08b7230 c9002000 ca402000 655360
> 6 c08b7240 c9002000 ca802000 786432
> 8 c08b7260 c8c02000 cac02000 1048576
> 9 c08b7270 c8c02000 cb002000 1179648
> 10 c08b7280 c8c02000 cb402000 1310720
> 12 c08b72a0 c8c02000 cbc02000 1572864
> ...
>
> This patch is a fix for this problem. nr_to_section() will check "addr" by
> IS_KVADDR() later anyway, so this patch just removes the problematic check.
I cannot recall exactly why that sanity check was put in place,
but it's clear that it only applies for CONFIG_SPARSEMEM_EXTREME
kernels. Thanks for catching that.
However, at least theoretically, the s390/s390x architectures
could be configured with CONFIG_SPARSEMEM_EXTREME, and in that
case "0" is considered a legitimate kernel virtual address.
But it would never be a legitimate mem_sec[] address.
So -- out of sheer paranoia -- instead of removing the check
completely, I will move it further down inside the subsequent
"if (IS_SPARSEMEM_EX())" section:
--- memory.c 5 Apr 2010 19:04:29 -0000 1.217
+++ memory.c 6 Apr 2010 14:23:21 -0000
@@ -13058,14 +13058,13 @@
}
}
- if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
- !IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
- return 0;
-
- if (IS_SPARSEMEM_EX())
+ if (IS_SPARSEMEM_EX()) {
+ if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
+ !IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
+ return 0;
addr = mem_sec[SECTION_NR_TO_ROOT(nr)] +
(nr & SECTION_ROOT_MASK()) * SIZE(mem_section);
- else
+ } else
addr = symbol_value("mem_section") +
(SECTIONS_PER_ROOT() * SECTION_NR_TO_ROOT(nr) +
(nr & SECTION_ROOT_MASK())) * SIZE(mem_section);
Thanks,
Dave
> Signed-off-by: Daisuke Nishimura <nishimura(a)mxp.nes.nec.co.jp>
> ---
> diff -uprN crash-5.0.2.orig/memory.c crash-5.0.2/memory.c
> --- crash-5.0.2.orig/memory.c 2010-04-05 16:08:52.000000000 +0900
> +++ crash-5.0.2/memory.c 2010-04-06 09:56:43.000000000 +0900
> @@ -13030,10 +13030,6 @@ nr_to_section(ulong nr)
> }
> }
>
> - if ((mem_sec[SECTION_NR_TO_ROOT(nr)] == 0) ||
> - !IS_KVADDR(mem_sec[SECTION_NR_TO_ROOT(nr)]))
> - return 0;
> -
> if (IS_SPARSEMEM_EX())
> addr = mem_sec[SECTION_NR_TO_ROOT(nr)] +
> (nr & SECTION_ROOT_MASK()) * SIZE(mem_section);
15 years, 1 month