[Crash-utility] Infinite loop during gathering of kmem slab cache data

Shawn Rhode srhode at egenera.com
Mon Mar 14 21:08:17 UTC 2011


I am seeing an issue when opening a crash file from RHEL AS 2.1 with the last 2.1 kernel released where crash will sit at "please wait... (gathering kmem slab cache data)" forever taking 100% of the CPU.  Turning on debugging at level 5 continuously prints out the following sequence over and over without stopping:
<readmem: f79d52cc, KVADDR, "kmem_cache buffer", 244, (ROE), 8585500>
<readmem: f79d5340, KVADDR, "cpudata array", 128, (ROE), ffffcbd0>
<readmem: f79d5344, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5344, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d534c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d534c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5354, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5354, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d535c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d535c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5364, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5364, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d536c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d536c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5374, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5374, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d537c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d537c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5384, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5384, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d538c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d538c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5394, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d5394, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d539c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d539c, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53a4, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53a4, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53ac, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53ac, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53b4, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53b4, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53bc, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d53bc, KVADDR, "cpucache limit", 4, (ROE), ffffcbcc>
<readmem: f79d52cc, KVADDR, "kmem_cache buffer", 244, (ROE), 8585500>
....

I am on the latest version of crash, 5.1.3:
[srhode at crash 1642489]$ crash32 -v

crash32 5.1.3
Copyright (C) 2002-2011  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 "--host=x86_64-unknown-linux-gnu --target=i686-pc-linux-gnu".

If I open the dump file using the "-no_kmem_cache" option, it opens, but I am not sure if this is causing other issues during analysis of the dump file.

Shawn Rhode
Principal Support Engineer - Egenera Global Technical Support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20110314/ec842aa4/attachment.htm>


More information about the Crash-utility mailing list