Please help: possible deadlock in kmem_alloc

Hello,

I have a Fedora Core 3 system (kernel 2.6.9-1.667smp) with an XFS filesystem
and from time to time the system crashes with errors like this on the
console (excerpts):

[<0213d396>] __alloc_pages+0x28b/0x298
[<0213d3bb>] __get_free_pages+0x18/0x24
[<0213fc88>] kmem_getpages+0x1c/0xbb
[<021407d9>] cache_grow+0xae/0x136
[<021409c6>] cache_alloc_refill+0x165/0x19d
[<02140d9d>] __kmalloc+0x76/0x88
[<82a3ee20>] kmem_alloc+0x50/0x9e [xfs]
[<82a22be6>] xfs_iread_extents+0x73/0xc4 [xfs]
[<82a0319a>] xfs_bmapi+0x2de/0x12bf [xfs]
[<02263fa6>] sk_reset_timer+0xc/0x16
[<0228ebee>] tcp_write_xmit+0x109/0x24c
[<022641b2>] release_sock+0xf/0x4f
[...]
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
Debug: sleeping function called from invalid context at mm/slab.c:2063

Ive been googling a lot about this errors but all I found were old threads
about kernel 2.1 or 2.4.

Can somebody help me to figure out what is goig on? The system is in
production (the XFS filesystem is an attached SCSI raid applicance) and I may
not have the full freedom to try different kernels or distribution at will.
At this point, I am interested to figure out what exactly the problem is.

Thank you,
Radu Filip
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Please help: possible deadlock in kmem_alloc

Hi,

Did you try to check and see if the RAM on the system is in good condition.
I mean all of the RAM is good. At points if some part of RAM is bad and when
the memory usage is high it may cause such problems.
You can do a extensive test by using memtest86 or something like that.
Or probably there is a third party tool that is causing memory violations.

Axl.

-----Original Message-----
From: linux-admin-owner@vger.kernel.org
[mailto:linux-admin-owner@vger.kernel.org] On Behalf Of Radu Filip
Sent: Tuesday, February 14, 2006 9:38 PM
To: linux-admin@vger.kernel.org
Subject: Please help: possible deadlock in kmem_alloc

Hello,

I have a Fedora Core 3 system (kernel 2.6.9-1.667smp) with an XFS filesystem

and from time to time the system crashes with errors like this on the
console (excerpts):

[<0213d396>] __alloc_pages+0x28b/0x298
[<0213d3bb>] __get_free_pages+0x18/0x24
[<0213fc88>] kmem_getpages+0x1c/0xbb
[<021407d9>] cache_grow+0xae/0x136
[<021409c6>] cache_alloc_refill+0x165/0x19d
[<02140d9d>] __kmalloc+0x76/0x88
[<82a3ee20>] kmem_alloc+0x50/0x9e [xfs]
[<82a22be6>] xfs_iread_extents+0x73/0xc4 [xfs]
[<82a0319a>] xfs_bmapi+0x2de/0x12bf [xfs]
[<02263fa6>] sk_reset_timer+0xc/0x16
[<0228ebee>] tcp_write_xmit+0x109/0x24c
[<022641b2>] release_sock+0xf/0x4f
[...]
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
possible deadlock in kmem_alloc (mode: 0xd0)
Debug: sleeping function called from invalid context at mm/slab.c:2063

Ive been googling a lot about this errors but all I found were old threads
about kernel 2.1 or 2.4.

Can somebody help me to figure out what is goig on? The system is in
production (the XFS filesystem is an attached SCSI raid applicance) and I
may
not have the full freedom to try different kernels or distribution at will.
At this point, I am interested to figure out what exactly the problem is.

Thank you,
Radu Filip
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Please help: possible deadlock in kmem_alloc

Hello,

Memory is OK, I have memtest (both Memtest86+ 1.40 and Memtest86 3.1a) as boot
options in GRUB. With the occasion of the last reboot, I let Memtest86 3.1a
to complete the first two tests and everything was fine.

Radu

On Tuesday 14 February 2006 10:25, Axl Purushu wrote:
> Hi,
>
> Did you try to check and see if the RAM on the system is in good condition.
> I mean all of the RAM is good. At points if some part of RAM is bad and
> when the memory usage is high it may cause such problems.
> You can do a extensive test by using memtest86 or something like that.
> Or probably there is a third party tool that is causing memory violations.
>
> Axl.
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html