From: Vivek Goyal <vgoyal@in.ibm.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: vgoyal@in.ibm.com, akpm@osdl.org, sharyathi@in.ibm.com,
fastboot@lists.osdl.org, linux-kernel@vger.kernel.org,
ebiederm@xmission.com
Subject: Re: [Fastboot] Re: Kdump Testing
Date: Thu, 28 Apr 2005 17:14:16 +0530 [thread overview]
Message-ID: <20050428114416.GA5706@in.ibm.com> (raw)
In-Reply-To: <20050427122312.358f5bd6.rddunlap@osdl.org>
On Wed, Apr 27, 2005 at 12:23:12PM -0700, Randy.Dunlap wrote:
> On Tue, 26 Apr 2005 14:24:48 +0530
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
>
> > >
> > > 2.6.12-rc2-mm3 reboots vmlinux-recover-UP on panic.
> > > (vmlinux-recover-SMP hangs during [early] reboot, but -UP
> > > goes further....)
> > >
> > > (BTW, how does I do serial console from the second
> > > kernel...? It has the drivers, but not the command
> > > line info? TBD.)
> > >
> >
> >
> > While pre-loading the capture kernel using kexec, you can specify the command
> > line options to second kernel using --append="". You must already be passing
> > the root device. Add you serial console parameters as well something like
> > --append="console=ttyS0, 38400"
> >
> >
> > > vmlinux-recover-UP gets to this point, hand-written,
> > > several lines missing:
> > >
> > > kfree_debugcheck: bad ptr c3dbffb0h. ( == %esi)
> > > kernel BUG at <bad filename>:23128!
> > > invalid operand: 0000 [#1]
> > > DEBUG_PAGEALLOC
> > > EIP is at kfree_debugcheck+0x45/0x50
> > >
> > > Stack dump shows lots of ext3 cache and inode functions...
> > >
> >
> > Can you post a full serial console output of second kernel? That would help.
>
> I did another test run, same kernels (both running and recovery).
> The recovery kernel got a little further this time, still had
> Badness and a BUG.
>
> ---
Ok. I am also able to see this slab corruption occurring on my machine. I can
get away with the problem if I disable cachefs support.
Infact, I can reproduce the problem if I boot capture kernel normally through
BIOS with commandline "mem=64M". Looks like it is generic problem and not
associated with kexec/kdump. Cachefs might be doing some corruption.
> CacheFS: Wrong magic number on cache
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 220k freed
> Adding 2104472k swap on /dev/hda7. Priority:42 extents:1
> mismatch in kmem_cache_free: expected cache c168fc80, got c4daca80
> c4daca80 is ext3_inode_cache.
> c168fc80 is skbuff_head_cache.
> Badness in cache_free_debugcheck at mm/slab.c:1917
> [<c1003368>] dump_stack+0x16/0x18
> [<c1041a94>] cache_free_debugcheck+0x88/0x1d5
> [<c10424fd>] kmem_cache_free+0x26/0x65
> [<c10a8c01>] ext3_destroy_inode+0x17/0x19
> [<c10784c9>] destroy_inode+0x27/0x3d
> [<c1078837>] dispose_list+0x60/0x178
> [<c1078f81>] prune_icache+0x363/0x399
> [<c1078fd0>] shrink_icache_memory+0x19/0x32
> [<c1044dd7>] shrink_slab+0x104/0x172
> [<c104641e>] try_to_free_pages+0xbe/0x16f
> [<c103d9a0>] __alloc_pages+0x1d3/0x393
> [<c104037c>] kmem_getpages+0x2d/0x7f
> [<c1041869>] cache_grow+0x155/0x2a8
> [<c1041f1f>] cache_alloc_refill+0x285/0x2c2
> [<c10423c6>] kmem_cache_alloc+0x5d/0x77
> [<c1075dac>] d_alloc+0x16/0x27a
> [<c106b2b9>] real_lookup+0x40/0xc2
> [<c106b68e>] do_lookup+0x41/0x75
> [<c106c3a7>] __link_path_walk+0xce5/0x1066
> [<c106c768>] link_path_walk+0x40/0xc7
> [<c106ca87>] path_lookup+0xec/0xf7
> [<c106cbc9>] __user_walk+0x28/0x42
> [<c10667b3>] vfs_lstat+0x17/0x3f
> [<c1066d1e>] sys_lstat64+0x13/0x29
> [<c1002c5f>] sysenter_past_esp+0x54/0x75
> slab error in cache_free_debugcheck(): cache `ext3_inode_cache': double free, or memory outside object was overwritten
> [<c1003368>] dump_stack+0x16/0x18
> [<c1041ad2>] cache_free_debugcheck+0xc6/0x1d5
> [<c10424fd>] kmem_cache_free+0x26/0x65
> [<c10a8c01>] ext3_destroy_inode+0x17/0x19
> [<c10784c9>] destroy_inode+0x27/0x3d
> [<c1078837>] dispose_list+0x60/0x178
> [<c1078f81>] prune_icache+0x363/0x399
> [<c1078fd0>] shrink_icache_memory+0x19/0x32
> [<c1044dd7>] shrink_slab+0x104/0x172
> [<c104641e>] try_to_free_pages+0xbe/0x16f
> [<c103d9a0>] __alloc_pages+0x1d3/0x393
> [<c104037c>] kmem_getpages+0x2d/0x7f
> [<c1041869>] cache_grow+0x155/0x2a8
> [<c1041f1f>] cache_alloc_refill+0x285/0x2c2
> [<c10423c6>] kmem_cache_alloc+0x5d/0x77
> [<c1075dac>] d_alloc+0x16/0x27a
> [<c106b2b9>] real_lookup+0x40/0xc2
> [<c106b68e>] do_lookup+0x41/0x75
> [<c106c3a7>] __link_path_walk+0xce5/0x1066
> [<c106c768>] link_path_walk+0x40/0xc7
> [<c106ca87>] path_lookup+0xec/0xf7
> [<c106cbc9>] __user_walk+0x28/0x42
> [<c10667b3>] vfs_lstat+0x17/0x3f
> [<c1066d1e>] sys_lstat64+0x13/0x29
> [<c1002c5f>] sysenter_past_esp+0x54/0x75
> c3d7afb0: redzone 1: 0x0, redzone 2: 0x0.
> ------------[ cut here ]------------
> kernel BUG at <bad filename>:18422!
> invalid operand: 0000 [#1]
> DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c1041b46>] Not tainted VLI
> EFLAGS: 00010002 (2.6.12-rc2-mm3)
> EIP is at cache_free_debugcheck+0x13a/0x1d5
> eax: c3d7a000 ebx: c3d7a000 ecx: 00001000 edx: 00000fb0
> esi: c3d7afb0 edi: c4daca80 ebp: c2f73bb8 esp: c2f73bac
> ds: 007b es: 007b ss: 0068
> Process showconsole (pid: 1264, threadinfo=c2f72000 task=c2f68ac0)
> Stack: c4d0fec4 c4daca80 c3d7bd44 c2f73be0 c10424fd c4daca80 c3d7bd44 c10a8c01
> 00000080 00000286 c3d7bddc c2f73c2c 00000080 c2f73bf0 c10a8c01 c4daca80
> c3d7bd44 c2f73c00 c10784c9 c3d7bddc c3d7bddc c2f73c1c c1078837 c3d7bddc
> Call Trace:
> [<c100334a>] show_stack+0x7a/0x82
> [<c1003453>] show_registers+0xe9/0x153
> [<c100369f>] die+0x15c/0x23d
> [<c1003a79>] do_invalid_op+0x90/0x97
> [<c1002ed3>] error_code+0x4f/0x54
> [<c10424fd>] kmem_cache_free+0x26/0x65
> [<c10a8c01>] ext3_destroy_inode+0x17/0x19
> [<c10784c9>] destroy_inode+0x27/0x3d
> [<c1078837>] dispose_list+0x60/0x178
> [<c1078f81>] prune_icache+0x363/0x399
> [<c1078fd0>] shrink_icache_memory+0x19/0x32
> [<c1044dd7>] shrink_slab+0x104/0x172
> [<c104641e>] try_to_free_pages+0xbe/0x16f
> [<c103d9a0>] __alloc_pages+0x1d3/0x393
> [<c104037c>] kmem_getpages+0x2d/0x7f
> [<c1041869>] cache_grow+0x155/0x2a8
> [<c1041f1f>] cache_alloc_refill+0x285/0x2c2
> [<c10423c6>] kmem_cache_alloc+0x5d/0x77
> [<c1075dac>] d_alloc+0x16/0x27a
> [<c106b2b9>] real_lookup+0x40/0xc2
> [<c106b68e>] do_lookup+0x41/0x75
> [<c106c3a7>] __link_path_walk+0xce5/0x1066
> [<c106c768>] link_path_walk+0x40/0xc7
> [<c106ca87>] path_lookup+0xec/0xf7
> [<c106cbc9>] __user_walk+0x28/0x42
> [<c10667b3>] vfs_lstat+0x17/0x3f
> [<c1066d1e>] sys_lstat64+0x13/0x29
> [<c1002c5f>] sysenter_past_esp+0x54/0x75
> Code: e8 bc e4 ff ff 8b 55 10 89 10 58 5a 8b 5b 0c 89 f0 31 d2 8b 4f 34 29 d8 f7 f1 3b 47 3c 72 02 0f 0b 0f af c1 8d 04 18 39 c6 74 02 <0f> 0b f6 47 39 02 74 15 6a 05 57 57 e8 1d e4 ff ff 8d 04 30 89
>
next prev parent reply other threads:[~2005-04-28 11:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-23 3:30 [Fastboot] Re: Kdump Testing Vivek Goyal
2005-04-25 12:15 ` Nagesh Sharyathi
2005-04-25 23:09 ` Randy.Dunlap
2005-04-26 8:54 ` Vivek Goyal
2005-04-27 16:46 ` Randy.Dunlap
2005-04-27 19:23 ` Randy.Dunlap
2005-04-28 11:44 ` Vivek Goyal [this message]
2005-04-28 16:11 ` Randy.Dunlap
2005-04-28 19:08 ` Eric W. Biederman
2005-04-29 3:08 ` [PATCH] Kdump docs Randy.Dunlap
2005-04-29 5:07 ` Vivek Goyal
2005-04-29 14:26 ` [Fastboot] " Randy.Dunlap
2005-04-30 3:04 ` [PATCH] Kdump doc. fix option typo Randy.Dunlap
-- strict thread matches above, loose matches on Subject: below --
2005-04-22 10:46 Kdump Testing Nagesh Sharyathi
2005-04-22 12:32 ` [Fastboot] " Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050428114416.GA5706@in.ibm.com \
--to=vgoyal@in.ibm.com \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
--cc=sharyathi@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.