Home » Mailing list archives » linux-kernel » 2011 » January » 4

Kernel 2.6.35.7 Oops caused by might_sleep() on ARMv7

Previous thread: [PATCH] RapidIO: Fix hang on RapidIO doorbell queue full condition by Thomas Taranowski on Tuesday, January 4, 2011 - 12:29 am. (1 message)

Next thread: declare MODULE_FIRMWARE in libsas by DuanZhenzhong on Tuesday, January 4, 2011 - 12:43 am. (3 messages)
[view original message]
From: ShiYong LI
Subject: Kernel 2.6.35.7 Oops caused by might_sleep() on ARMv7
Date: Tuesday, January 4, 2011 - 12:40 am

Hi,

I'm getting kernel run on OMAP4430 chip (ARMv7, dual core), and got an
unexpected Oops caused by might_sleep() function. While that happened,
I was performing system test which almost consumed all system memory.

Based on Oops log below, might_sleep() threw out an unexpected warning
in page fault exception triggered by short of memory while calling
system call (by SWI exception). This should be a normal scenario, but,
kernel doesn't seem to handle it fine.  Any thoughts ?

Oops log:

<6>[35377.073242] request_suspend_state: wakeup (0->0) at
32812699437166 (2010-12-29 19:08:41.273678467 UTC)
<6>[35379.468200] input: sensors as /devices/virtual/input/input9
<6>[35380.344421] usb_ether_get_stats
<6>[35380.362335] usb_ether_get_stats
<6>[35380.399444] usb_ether_get_stats
<6>[35380.417022] usb_ether_get_stats
<6>[35380.618469] usb_ether_get_stats
<3>[35391.279327] init: untracked pid 25171 exited
<4>[35393.306610] events/0: page allocation failure. order:1, mode:0x20
<4>[35393.313140] [<c004b7a0>] (unwind_backtrace+0x0/0xf0) from
[<c00f2df8>] (__alloc_pages_nodemask+0x568/0x6e8)
<4>[35393.323455] [<c00f2df8>] (__alloc_pages_nodemask+0x568/0x6e8)
from [<c0117a64>] (cache_grow.clone.0+0xac/0x3e8)
<4>[35393.334167] [<c0117a64>] (cache_grow.clone.0+0xac/0x3e8) from
[<c011a0a0>] (__kmalloc_track_caller+0x3f4/0x6cc)
<4>[35393.344848] [<c011a0a0>] (__kmalloc_track_caller+0x3f4/0x6cc)
from [<c0373264>] (__alloc_skb+0x50/0xe0)
<4>[35393.354827] [<c0373264>] (__alloc_skb+0x50/0xe0) from
[<bf030020>] (st_int_recv+0x370/0x48c [st_drv])
<4>[35393.364593] [<bf030020>] (st_int_recv+0x370/0x48c [st_drv]) from
[<bf02f018>] (st_tty_receive+0x18/0x20 [st_drv])
<4>[35393.375488] [<bf02f018>] (st_tty_receive+0x18/0x20 [st_drv])
from [<c0240ae0>] (flush_to_ldisc+0xe0/0x180)
<4>[35393.385711] [<c0240ae0>] (flush_to_ldisc+0xe0/0x180) from
[<c00a4cac>] (worker_thread+0x1e4/0x278)
<4>[35393.395202] [<c00a4cac>] (worker_thread+0x1e4/0x278) from
[<c00a8ab0>] (kthread+0x78/0x80)
<4>[35393.403961] ...
[ message continues ]
Previous thread: [PATCH] RapidIO: Fix hang on RapidIO doorbell queue full condition by Thomas Taranowski on Tuesday, January 4, 2011 - 12:29 am. (1 message)

Next thread: declare MODULE_FIRMWARE in libsas by DuanZhenzhong on Tuesday, January 4, 2011 - 12:43 am. (3 messages)