>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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
