Andrew Athan wrote:AmÃrico Wang wrote:On Tue, Jan 12, 2010 at 10:55 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:Due to remote location of the hardware and I haven't been able to test a more recent (or older) kernel. Remote hands have put a KVM on the box as of an hour ago, so I hope to have some information for you in a day or two.
On Tue, 2010-01-12 at 22:52 +0800, AmÃrico Wang wrote:
Does a recent kernel work?$ uname -a
Linux UK22 2.6.30-2-amd64 #1 SMP Fri Sep 25 22:16:56 UTC 2009 x86_64
Ah, I just wanted to ask the same question, adding the original reporter
Gong Cheng into Cc...
Gong, could you reproduce it on the latest kernel? And what is your .config?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I wanted to report that although I have had no luck (so far) running anything more recent than 2.6.30, I was able to revert to 2.6.26. Unfortunately, the application hang still occurs. I also saw a similar hang of the application running on a 32 bit Intel box, also under 2.6.26. So far, the hang *always* involves threads stuck on pthread_cond_broadcast()'s condition variable's internal lock while other threads are waiting on the outer "public" lock.
These other threads are *not* yet (nor about to) pthread_cond_wait(). I saw a message from Darren Hart (subject "Re: Problems with futex") in response to someone who apparently was having futex problems in 2.6.27, so I'm still operating under the assumption that this is not an application bug.
Over the next couple of days, I will be running a version of the application in which I replaced the pthread_cond calls with simpler locks, in the hopes that it won't hang (because I'm hoping the underlying implementation in pthreads uses a different set of futex opcodes).