From: blacknred <leo1783@hotmail.co.uk>
To: xfs@oss.sgi.com
Subject: Re: kernel panic-xfs errors
Date: Thu, 9 Dec 2010 05:17:03 -0800 (PST) [thread overview]
Message-ID: <30416394.post@talk.nabble.com> (raw)
In-Reply-To: <4D005E99.2030400@sandeen.net>
>which is NOT a rhel 5.0 kernel, and it says x86_64.
>But the addresses are all 32 bits?
My apologies there, somehow it all got jumbled up, pasting it again:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000098
printing eip:
*pde = 2c621001
Oops: 0000 [#1]
SMP
CPU: 2
EIP: 0060:[<c0619da1>] Tainted: GF VLI
EFLAGS: 00010282 (2.6.18-164.11.1.el5PAE #1)
EIP is at do_page_fault+0x205/0x607
eax: ec6de000 ebx: 00000000 ecx: ec6de074 edx: 0000000d
esi: 00014005 edi: ec6de0a4 ebp: 00000014 esp: ec6de054
ds: 007b es: 007b ss: 0068
Process bm (pid: 2910, ti=ec6dd000 task=ec6e3550 task.ti=ec6dd000)
Stack: 00000000 00000000 ec6de0a4 00000014 00000098 f7180000 00000001
00000000
ec6de0a4 c0639439 00000000 0000000e 0000000b 00000000 00000000
00000000
00014005 c0619b9c 00000014 c0405a89 00000000 ec6de0f8 0000000d
00014005
Call Trace:
[<c0619b9c>] do_page_fault+0x0/0x607
[<c0405a89>] error_code+0x39/0x40
[<c0619da1>] do_page_fault+0x205/0x607
[<c04dc33c>] elv_next_request+0x127/0x134
[<f893575c>] do_cciss_request+0x398/0x3a3 [cciss]
[<c0619b9c>] do_page_fault+0x0/0x607
[<c0405a89>] error_code+0x39/0x40
[<c0619da1>] do_page_fault+0x205/0x607
[<c04e4dad>] deadline_set_request+0x16/0x57
[<c0619b9c>] do_page_fault+0x0/0x607
[<c0405a89>] error_code+0x39/0x40
[<c0619da1>] do_page_fault+0x205/0x607
[<c0619b9c>] do_page_fault+0x0/0x607
[<c0405a89>] error_code+0x39/0x40
[<c0619da1>] do_page_fault+0x205/0x607
[<c0619b9c>] do_page_fault+0x0/0x607
[<c0405a89>] error_code+0x39/0x40
[<c0618b74>] __down+0x2b/0xbb
[<c041fb73>] default_wake_function+0x0/0xc
[<c0616b5f>] __down_failed+0x7/0xc
[<f8a6f3d4>] .text.lock.xfs_buf+0x17/0x5f [xfs]
[<f8a6ee89>] xfs_buf_read_flags+0x48/0x76 [xfs]
[<f8a62982>] xfs_trans_read_buf+0x1bb/0x2c0 [xfs]
[<f8a3b029>] xfs_btree_read_bufl+0x96/0xb3 [xfs]
[<f8a38be7>] xfs_bmbt_lookup+0x135/0x478 [xfs]
[<f8a302b4>] xfs_bmap_add_extent+0xd2b/0x1e30 [xfs]
[<f8a26446>] xfs_alloc_update+0x3a/0xbc [xfs]
[<f8a21ae3>] xfs_alloc_fixup_trees+0x217/0x29a [xfs]
[<f8a625ef>] xfs_trans_log_buf+0x49/0x6c [xfs]
[<f8a21b86>] xfs_alloc_search_busy+0x20/0xae [xfs]
[<f8a4e07c>] xfs_iext_bno_to_ext+0xd8/0x191 [xfs]
[<f8a6bec2>] kmem_zone_zalloc+0x1d/0x41 [xfs]
[<f8a33165>] xfs_bmapi+0x15fe/0x2016 [xfs]
[<f8a4dfec>] xfs_iext_bno_to_ext+0x48/0x191 [xfs]
[<f8a31a6e>] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs]
[<f8a5407f>] xfs_iomap_write_allocate+0x29c/0x469 [xfs]
[<c042d85d>] lock_timer_base+0x15/0x2f
[<c042dd18>] del_timer+0x41/0x47
[<f8a52d19>] xfs_iomap+0x409/0x71d [xfs]
[<f8a6c873>] xfs_map_blocks+0x29/0x52 [xfs]
[<f8a6cc6f>] xfs_page_state_convert+0x37b/0xd2e [xfs]
[<f8a31358>] xfs_bmap_add_extent+0x1dcf/0x1e30 [xfs]
[<f8a31a6e>] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs]
[<f8a31dd9>] xfs_bmapi+0x272/0x2016 [xfs]
[<f8a333ba>] xfs_bmapi+0x1853/0x2016 [xfs]
[<c04561ae>] find_get_pages_tag+0x30/0x75
[<f8a6d82b>] xfs_vm_writepage+0x8f/0xc2 [xfs]
[<c0493f1c>] mpage_writepages+0x1a7/0x310
[<f8a6d79c>] xfs_vm_writepage+0x0/0xc2 [xfs]
[<c045b423>] do_writepages+0x20/0x32
[<c04926f7>] __writeback_single_inode+0x170/0x2af
[<c049289c>] write_inode_now+0x66/0xa7
[<c0476855>] file_fsync+0xf/0x6c
[<f8b9b75b>] moddw_ioctl+0x420/0x669 [mod_dw]
[<c0420f74>] __cond_resched+0x16/0x34
[<c04844d8>] do_ioctl+0x47/0x5d
[<c0484a41>] vfs_ioctl+0x47b/0x4d3
[<c0484ae1>] sys_ioctl+0x48/0x5f
[<c0404ead>] sysenter_past_esp+0x56/0x79
Thanks, sorry for the confusion....
Eric Sandeen-3 wrote:
>
> On 12/8/10 6:59 PM, Dave Chinner wrote:
>> On Wed, Dec 08, 2010 at 01:39:10AM -0800, blacknred wrote:
>>>
>>>
>>>> You've done a forced module load. No guarantee your kernel is in any
>>>> sane shape if you've done that....
>>>
>>> Agree, but I'm reasonably convinced that module isn't the issue, because
>>> it
>>> works fine with my other servers......
>>>
>>>> Strange failure. Hmmm - i386 arch and fedora - are you running with
>>> 4k stacks? If so, maybe it blew the stack...
>>>
>>> i386 arch, rhel 5.0
>>
>> Yup, 4k stacks. This is definitely smelling like a stack blowout.
>
> well, hang on. The oops said:
>
> EIP: 0060:[<c0529da1>] Tainted: GF VLI
> EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1)
> EIP is at do_page_fault+0x245/0x617
> eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e
> esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024
> ds: 008b es: 008b ss: 0078
>
> which is NOT a rhel 5.0 kernel, and it says x86_64.
>
> But the addresses are all 32 bits?
>
> So what's going on here?
>
>> esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024
>> ds: 008b es: 008b ss: 0078
>> Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000)
>
> end of the stack is ec6ee000, stack grows up, esp is at ec5de024,
> well past it (i.e. yes, overrun) if I remember my stack math
> right... but that's a pretty huge difference so either I have it
> wrong, or things are really a huge mess here.
>
> -Eric
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
>
--
View this message in context: http://old.nabble.com/kernel-panic-xfs-errors-tp30397503p30416394.html
Sent from the Xfs - General mailing list archive at Nabble.com.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-12-09 13:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 15:42 kernel panic-xfs errors blacknred
2010-12-07 15:59 ` Emmanuel Florac
2010-12-07 17:20 ` blacknred
2010-12-07 18:00 ` Emmanuel Florac
2010-12-07 18:18 ` Stan Hoeppner
2010-12-07 21:52 ` Emmanuel Florac
2010-12-07 22:25 ` Dave Chinner
2010-12-08 9:39 ` blacknred
2010-12-08 10:57 ` Emmanuel Florac
2010-12-08 14:01 ` blacknred
2010-12-08 14:34 ` Emmanuel Florac
2010-12-09 0:59 ` Dave Chinner
2010-12-09 4:44 ` Eric Sandeen
2010-12-09 13:17 ` blacknred [this message]
2010-12-09 14:56 ` Eric Sandeen
2010-12-09 13:23 ` blacknred
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=30416394.post@talk.nabble.com \
--to=leo1783@hotmail.co.uk \
--cc=xfs@oss.sgi.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.