pthread_mutex_timedlock on sparc64

[Joerg Pulz]

-----BEGIN PGP SIGNED MESSAGE-----
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 freebsd.org 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/libpthread.so
>>>>>>> lrwxrwxrwx  1 root  wheel  9 Apr 17 04:05 /usr/lib/libpthread.so ->
>>>>>>> libc_r.so
>>>>>>
>>>>>> 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.

Kris,

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.
Joerg

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

iD8DBQFESS7DSPOsGF+KA+MRAt5+AJ91hNZ1duFYmjDe3aLABE2JuE6f9ACdHOHc
jKzltWxtLNdMXkEp0Ck1n4Y=
=hnK1
-----END PGP SIGNATURE-----