On 2/2/2011 2:33 PM, Nitin Garg wrote: > Are we including this fix for .32 release? > > Regards, > Nitin >
I expect that everything is currently on master, will go into .32 stable. I don't know if Bernard wants to tag a .32-rc3 before. > On Tue, Feb 1, 2011 at 12:54 PM, Nitin Garg <[email protected]> wrote: > > Carmelo and Khem, > > > > I tested by removing > > uClibc/libpthread/nptl/sysdeps/unix/sysv/linux/arm/bits/atomic.h file > > and adding uClibc/libc/sysdeps/linux/arm/bits/atomic.h. This file I > > added is derived from glibc and uses swp instructions for atomic > > operations (the nptl atomic functions do not). I tested on Cortex-A9 > > and do no see any issues with the attached patch. > > > > Regards, > > Nitin > > > > On Tue, Feb 1, 2011 at 10:25 AM, Carmelo AMOROSO <[email protected]> > wrote: > On 2/1/2011 5:21 PM, Khem Raj wrote: >> >>> On Tue, Feb 1, 2011 at 8:17 AM, Carmelo AMOROSO >> <[email protected]> wrote: >> >>> On 2/1/2011 5:14 PM, Nitin Garg wrote: >> >>>> >> Hope I created the patch correctly. Pls let me know if this is >> >>>> >> incorrect, otherwise pls add it to repository. >> >>>> >> >> >>>> >> Thanks, >> >>>> >> Nitin >> >>>> >> >> >>> >> >>> Nitin, >> >>> according to the comment by Thomas, I've understood that we already have >> >>> a good implementation in the nptl path, it should be just the case to >> >>> fix the buildsys to properly pick-up the right one. >> >>> >> >>> I will check... Khem ? >> >>> >> >>>> yes thats fine too it will fix nptl I thought moving it to common arm >> >>>> would make it LT use it too but probably fixing just for nptl it >> >>>> better >> >>> > > so a git mv libpthread/nptl/...../bits/atomic.h to libc/sysdeps/.... > would be enough. > > Niting, would you like to try on your env before ? > > Thanks, > Carmelo > >> >>> Carmelo >> >>> >> >>>> >> On Tue, Feb 1, 2011 at 1:13 AM, Khem Raj <[email protected]> wrote: >> >>>> >> > On (01/02/11 00:32), Nitin Garg wrote: >> >>>> >> >> Recently we came accross an issue on ARMv7 processors while >> running >> >>>> >> >> multiple threads. If say 3 threads are running continuously, 1 >> or 2 >> >>>> >> >> might get locked somewhere. If we attach gdb and run again, all 3 >> >>>> >> >> threads start executing for a while and after some time 1 or 2 >> threads >> >>>> >> >> gets locked-up again. The backtrace showed the threads are stuck >> in >> >>>> >> >> __pthread_mutex_lock (atomic_compare_and_exchange_val_acq). >> >>>> >> >> >> >>>> >> >> We noticed that the atomic compare and exchange functions are not >> >>>> >> >> atomic for ARM. Once we added the Atomic compare and exchange >> >>>> >> >> function, the problem was resolved. >> >>>> >> >> >> >>>> >> >> Pls see below patch for review and kindly add it to next release. >> >>>> >> > >> >>>> >> > This looks ok to me but you have to send a properly formatted and >> >>>> >> > signed-off patch so it can be tested and included. Using git >> format-patch >> >>>> >> > and git send-email is your best bet >> >>>> >> > >> >>>> >> > -Khem >> >>>> >> > >> >>>> >> >> >>> > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc >> >>> > > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc > >> > > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
