[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4601170E.7080901@nagafix.co.uk>
Date: Wed, 21 Mar 2007 11:29:18 +0000
From: Antoine Martin <antoine@...afix.co.uk>
To: linux-kernel@...r.kernel.org, mathieu.desnoyers@...ymtl.ca,
mbligh@...igh.org
Subject: Re: Bug report : reproducible memory allocator bug in 2.6.20-rc6
Re:
http://lkml.org/lkml/2007/1/28/146
Just got a similar OOPS on a system under heavy load (transcode + p2p),
with kernel 2.6.20.3 / x86_64 (in free_block).
[<ffffffff802c5b95>] free_block+0xae/0x13c
[<ffffffff802c5cb6>] drain_array+0x93/0xd1
[<ffffffff802c6820>] cache_reap+0xea/0x239
[<ffffffff802c6736>] cache_reap+0x0/0x239
[<ffffffff8024a644>] run_workqueue+0x95/0x140
[<ffffffff802471e5>] worker_thread+0x0/0x150
[<ffffffff802472ff>] worker_thread+0x11a/0x150
[<ffffffff80284806>] default_wake_function+0x0/0xe
[<ffffffff802319e7>] kthread+0xd1/0x100
[<ffffffff8025aec8>] child_rip+0xa/0x12
[<ffffffff80231916>] kthread+0x0/0x100
[<ffffffff8025aebe>] child_rip+0x0/0x12
Not sure this is relevant, but transcode uses nice/ionice:
ionice -n 7 -c 3 nice -n 19 transcode [...]
No forced pre-emption, 100HZ, etc...
Note: this is not an SMP system, just a SMP kernel. So if it is a race,
it is not an SMP triggered race. (or I could just be unlucky again -
damn those cosmic rays)
Antoine
View attachment "summary.txt" of type "text/plain" (7801 bytes)
Powered by blists - more mailing lists