pthread_mutex_timedlock on sparc64

Joerg Pulz Joerg.Pulz at
Fri Apr 21 19:13:23 UTC 2006

Hash: SHA1

On Thu, 20 Apr 2006, Kris Kennaway wrote:

> On Thu, Apr 20, 2006 at 08:01:36AM +0200, Joerg Pulz wrote:
>> On Wed, 19 Apr 2006, Daniel Eischen wrote:
>>> On Wed, 19 Apr 2006, Kris Kennaway wrote:
>>>> On Wed, Apr 19, 2006 at 03:32:18PM +1000, Sean Winn wrote:
>>>>> Kris Kennaway wrote:
>>>>>> On Tue, Apr 18, 2006 at 07:28:00PM +1000, Sean Winn wrote:
>>>>>>> owner-freebsd-sparc64 at wrote:
>>>>>>>> libthr *is* the thread library on sparc64; as Daniel says,
>>>>>>>> libpthread is not ported to sparc64.
>>>>>>>> Kris
>>>>>>> Not yet in 6.x
>>>>>>> 19:25 Tue 18-Apr sean at bloody [~] uname -msr
>>>>>>> FreeBSD 6.1-RC1 sparc64
>>>>>>> 19:25 Tue 18-Apr sean at bloody [~] ls -l /usr/lib/
>>>>>>> lrwxrwxrwx  1 root  wheel  9 Apr 17 04:05 /usr/lib/ ->
>>>>>> Oops, I forgot about that..although so did David when he removed
>>>>>> libc_r from 7.0 and broke sparc :-)
>>>>>> So I guess this is a libc_r missing feature.  Probably the solution is
>>>>>> to use libthr on 6.x too (I don't know if it works well enough on
>>>>>> 5.x).  libthr causes witness panics under load on sparc64 though.
>>>>>> Kris
>>>>> Would threading problems be related to sparc64/73413? I've noticed it
>>>>> sitting idle for a long while, and the test case still core dumps. The
>>>>> PR it references (sparc64/72998) also is open.
>>>> Huh, turns out libpthread does exist on sparc, it's just called
>>>> libkse.  Anyway, since it's not in use the PR wasn't relevant.
>>> Yeah, I implemented as much as I could for it, but it doesn't
>>> work.  So it's installed as libkse as a prod for someone to
>>> finish and test it.
>> First, thanks for all your responses.
>> I found an Ultra 10 machine in a dark corner of my office an reactivated
>> it.
>> Installation went fine, the system is not very fast but runs without
>> problems. Unfortunately, it is an IDE system, so disk access is a bit
>> slow.
>> It runs now a RELENG_6_1 and it is correct that the
>> "pthread_mutex_timedlock" symbol is missing in libpthread, which is
>> actually a link to libc_r. The "pthread_mutex_timedlock" is only in libthr
>> and libkse, which is actually libpthread on sparc64 and alpha according to
>> src/lib/libpthread/Makefile.
>> I decided to give libkse a try and started building net/openmcu and all
>> ports it depends on with 'make PTHREAD_LIBS="-lkse"' and so far, compiling
>> and linking was fine. But as soon as i try to execute the resulting
>> binary, it dumps core. Currently i did no further investigation on this.
> Yes, as discussed upthread libkse is known not to work.  libthr should
> be fine though (since the port builds on 7.0).
> Hopefully David or someone will be able to look at the WITNESS panics
> from libthr on sparc soon.  Then we can make libthr the default on
> FreeBSD 6.x as well.
> In the meantime, you might be able to force the port to use libthr on
> 5.x/6.x, but this may not work since you typically encounter problems
> if different thread libraries are mixed in the same binary.  If not,
> the port should probably be marked BROKEN on sparc/5.x and 6.x until
> the change can be made.


you're right, forcing the port to use libthr didn't work.
I submitted PR's to mark it BROKEN for sparc64 && OSVERSION <= 700003
as the __FreeBSD_version bump to 700004 was exactly three days after the 
default thread library for sparc64 was changed from libc_r to libthr.

The changes for net/gatekeeper and net/openmcu are in the tree. The 
PR/96137 for net/openam is pending.

Thanks for all your help.

- -- 
The beginning is the most important part of the work.
Version: GnuPG v1.4.3 (FreeBSD)


More information about the freebsd-threads mailing list