pthread_mutex_timedlock on sparc64

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-sparc64freebsd.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 seanbloody [~] uname -msr
> >> FreeBSD 6.1-RC1 sparc64
> >> 19:25 Tue 18-Apr seanbloody [~] 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.

Kris

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-sparc64freebsd.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 seanbloody [~] uname -msr
>>>> FreeBSD 6.1-RC1 sparc64
>>>> 19:25 Tue 18-Apr seanbloody [~] 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.

-- 
DE
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On Wed, Apr 19, 2006 at 08:37:17AM -0400, 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-sparc64freebsd.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 seanbloody
[~] uname -msr
> >>>>FreeBSD 6.1-RC1 sparc64
> >>>>19:25 Tue 18-Apr seanbloody
[~] 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.

OK, the PRs should just be suspended then.

We need a list of the many unfinished or unimplemented bits
of
FreeBSD/sparc :(

Kris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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-sparc64freebsd.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 seanbloody
[~] uname -msr
>>>>> FreeBSD 6.1-RC1 sparc64
>>>>> 19:25 Tue 18-Apr seanbloody
[~] 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.

I will start another run today, to give libthr a try. Lets
see how this 
works.

Anyway, i will submit PR's for the relevant ports to please
pointyhat.

Kind regards
Joerg

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

iD8DBQFERyPDSPOsGF+KA+MRAhWVAJ90MXngOQ/4ZgxeGnwwtEHZ85ZbPgCg
kvHA
snZ93oL9FspaUYQLa0OuR7Q=
=H+fl
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

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-sparc64freebsd.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 seanbloody
[~] uname -msr
> >>>>> FreeBSD 6.1-RC1 sparc64
> >>>>> 19:25 Tue 18-Apr seanbloody
[~] 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

On Friday 21 April 2006 02:23, Kris Kennaway wrote:

> 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

Do you have WITNESS backtrace ? I don't have sparc
hardware.

David Xu
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On Fri, Apr 21, 2006 at 07:17:22AM +0800, David Xu wrote:
> On Friday 21 April 2006 02:23, Kris Kennaway wrote:
> 
> > 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
> 
> Do you have WITNESS backtrace ? I don't have sparc
hardware.

Actually I mis-remembered a bit.

> panic: _mtx_lock_sleep: recursed on non-recursive mutex
system map  ../../../vm/vm_map.c:2993
> panic() at panic+0x164
> _mtx_lock_sleep() at _mtx_lock_sleep+0x40
> _mtx_lock_flags() at _mtx_lock_flags+0x98
> _vm_map_lock_read() at _vm_map_lock_read+0x1c
> vm_map_lookup() at vm_map_lookup+0x1c
> vm_fault() at vm_fault+0x68
> trap_pfault() at trap_pfault+0x1a8
> trap() at trap+0x2b0
> -- fast data access mmu miss tar=0xe85a6000
%o7=0xc02f3b08 --
> vm_map_entry_splay() at vm_map_entry_splay+0x10
> vm_map_find() at vm_map_find+0x34
> kmem_alloc_nofault() at kmem_alloc_nofault+0x44
> vm_thread_new() at vm_thread_new+0x44
> thread_init() at thread_init+0x8
> slab_zalloc() at slab_zalloc+0x264
> uma_zone_slab() at uma_zone_slab+0x1ac
> uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4
> uma_zalloc_arg() at uma_zalloc_arg+0x398
> thread_alloc() at thread_alloc+0x18
> create_thread() at create_thread+0x78
> thr_new() at thr_new+0x64
> syscall() at syscall+0x2dc
> -- syscall (455, FreeBSD ELF64, thr_new) %o7=0x40348e7c
--

It may be a deeper vm problem.

Kris

On Friday 21 April 2006 07:25, Kris Kennaway wrote:

> > Do you have WITNESS backtrace ? I don't have
sparc hardware.
>
> Actually I mis-remembered a bit.
>
> > panic: _mtx_lock_sleep: recursed on non-recursive
mutex system map 
> > ../../../vm/vm_map.c:2993 panic() at panic+0x164
> > _mtx_lock_sleep() at _mtx_lock_sleep+0x40
> > _mtx_lock_flags() at _mtx_lock_flags+0x98
> > _vm_map_lock_read() at _vm_map_lock_read+0x1c
> > vm_map_lookup() at vm_map_lookup+0x1c
> > vm_fault() at vm_fault+0x68
> > trap_pfault() at trap_pfault+0x1a8
> > trap() at trap+0x2b0
> > -- fast data access mmu miss tar=0xe85a6000
%o7=0xc02f3b08 --
> > vm_map_entry_splay() at vm_map_entry_splay+0x10
> > vm_map_find() at vm_map_find+0x34
> > kmem_alloc_nofault() at kmem_alloc_nofault+0x44
> > vm_thread_new() at vm_thread_new+0x44
> > thread_init() at thread_init+0x8
> > slab_zalloc() at slab_zalloc+0x264
> > uma_zone_slab() at uma_zone_slab+0x1ac
> > uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4
> > uma_zalloc_arg() at uma_zalloc_arg+0x398
> > thread_alloc() at thread_alloc+0x18
> > create_thread() at create_thread+0x78
> > thr_new() at thr_new+0x64
> > syscall() at syscall+0x2dc
> > -- syscall (455, FreeBSD ELF64, thr_new)
%o7=0x40348e7c --
>
> It may be a deeper vm problem.
>
> Kris

I think it is a bug of some VM allocation code, it probably
should be
reported on -CURRENT.

David Xu
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

> > panic: _mtx_lock_sleep: recursed on non-recursive
mutex system map  ../../../vm/vm_map.c:2993
> > panic() at panic+0x164
> > _mtx_lock_sleep() at _mtx_lock_sleep+0x40
> > _mtx_lock_flags() at _mtx_lock_flags+0x98
> > _vm_map_lock_read() at _vm_map_lock_read+0x1c
> > vm_map_lookup() at vm_map_lookup+0x1c
> > vm_fault() at vm_fault+0x68
> > trap_pfault() at trap_pfault+0x1a8
> > trap() at trap+0x2b0

This is a bug in the sparc64 pmap implementation. The kernel
shouldn't
be taking page faults at this point.

     -Kip


> > -- fast data access mmu miss tar=0xe85a6000
%o7=0xc02f3b08 --
> > vm_map_entry_splay() at vm_map_entry_splay+0x10
> > vm_map_find() at vm_map_find+0x34
> > kmem_alloc_nofault() at kmem_alloc_nofault+0x44
> > vm_thread_new() at vm_thread_new+0x44
> > thread_init() at thread_init+0x8
> > slab_zalloc() at slab_zalloc+0x264
> > uma_zone_slab() at uma_zone_slab+0x1ac
> > uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4
> > uma_zalloc_arg() at uma_zalloc_arg+0x398
> > thread_alloc() at thread_alloc+0x18
> > create_thread() at create_thread+0x78
> > thr_new() at thr_new+0x64
> > syscall() at syscall+0x2dc
> > -- syscall (455, FreeBSD ELF64, thr_new)
%o7=0x40348e7c --
>
> It may be a deeper vm problem.
>
> Kris
>
>
>
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On Thursday 20 April 2006 10:42 pm, Kip Macy wrote:
> > > panic: _mtx_lock_sleep: recursed on
non-recursive mutex system map 
> > > ../../../vm/vm_map.c:2993 panic() at
panic+0x164
> > > _mtx_lock_sleep() at _mtx_lock_sleep+0x40
> > > _mtx_lock_flags() at _mtx_lock_flags+0x98
> > > _vm_map_lock_read() at _vm_map_lock_read+0x1c
> > > vm_map_lookup() at vm_map_lookup+0x1c
> > > vm_fault() at vm_fault+0x68
> > > trap_pfault() at trap_pfault+0x1a8
> > > trap() at trap+0x2b0
>
> This is a bug in the sparc64 pmap implementation. The
kernel shouldn't
> be taking page faults at this point.

Couldn't it be a NULL pointer deref in
vm_map_entry_splay()?

> > > -- fast data access mmu miss tar=0xe85a6000
%o7=0xc02f3b08 --
> > > vm_map_entry_splay() at
vm_map_entry_splay+0x10
> > > vm_map_find() at vm_map_find+0x34
> > > kmem_alloc_nofault() at
kmem_alloc_nofault+0x44
> > > vm_thread_new() at vm_thread_new+0x44
> > > thread_init() at thread_init+0x8
> > > slab_zalloc() at slab_zalloc+0x264
> > > uma_zone_slab() at uma_zone_slab+0x1ac
> > > uma_zalloc_bucket() at
uma_zalloc_bucket+0x1b4
> > > uma_zalloc_arg() at uma_zalloc_arg+0x398
> > > thread_alloc() at thread_alloc+0x18
> > > create_thread() at create_thread+0x78
> > > thr_new() at thr_new+0x64
> > > syscall() at syscall+0x2dc
> > > -- syscall (455, FreeBSD ELF64, thr_new)
%o7=0x40348e7c --
> >
> > It may be a deeper vm problem.
> >
> > Kris
>
> _______________________________________________
> freebsd-sparc64freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc
64
> To unsubscribe, send any mail to
"freebsd-sparc64-unsubscribefreebsd.org"

-- 
John Baldwin <jhbFreeBSD.org>  <><  http://www.FreeBSD.org/~
jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On 4/21/06, John Baldwin <jhbfreebsd.org> wrote:
> On Thursday 20 April 2006 10:42 pm, Kip Macy wrote:
> > > > panic: _mtx_lock_sleep: recursed on
non-recursive mutex system map 
> > > > ../../../vm/vm_map.c:2993 panic() at
panic+0x164
> > > > _mtx_lock_sleep() at
_mtx_lock_sleep+0x40
> > > > _mtx_lock_flags() at
_mtx_lock_flags+0x98
> > > > _vm_map_lock_read() at
_vm_map_lock_read+0x1c
> > > > vm_map_lookup() at vm_map_lookup+0x1c
> > > > vm_fault() at vm_fault+0x68
> > > > trap_pfault() at trap_pfault+0x1a8
> > > > trap() at trap+0x2b0
> >
> > This is a bug in the sparc64 pmap implementation.
The kernel shouldn't
> > be taking page faults at this point.
>
> Couldn't it be a NULL pointer deref in
vm_map_entry_splay()?

Good point. If this "0xe85a6000" is the page
address then it is something else.
           -Kip

>
> > > > -- fast data access mmu miss
tar=0xe85a6000 %o7=0xc02f3b08 --
> > > > vm_map_entry_splay() at
vm_map_entry_splay+0x10
> > > > vm_map_find() at vm_map_find+0x34
> > > > kmem_alloc_nofault() at
kmem_alloc_nofault+0x44
> > > > vm_thread_new() at vm_thread_new+0x44
> > > > thread_init() at thread_init+0x8
> > > > slab_zalloc() at slab_zalloc+0x264
> > > > uma_zone_slab() at uma_zone_slab+0x1ac
> > > > uma_zalloc_bucket() at
uma_zalloc_bucket+0x1b4
> > > > uma_zalloc_arg() at uma_zalloc_arg+0x398
> > > > thread_alloc() at thread_alloc+0x18
> > > > create_thread() at create_thread+0x78
> > > > thr_new() at thr_new+0x64
> > > > syscall() at syscall+0x2dc
> > > > -- syscall (455, FreeBSD ELF64, thr_new)
%o7=0x40348e7c --
> > >
> > > It may be a deeper vm problem.
> > >
> > > Kris
> >
> > _______________________________________________
> > freebsd-sparc64freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc
64
> > To unsubscribe, send any mail to
"freebsd-sparc64-unsubscribefreebsd.org"
>
> --
> John Baldwin <jhbFreeBSD.org>
<>< http://www.FreeBSD.org/~
jhb/
> "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

-----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-sparc64freebsd.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 seanbloody
[~] uname -msr
>>>>>>> FreeBSD 6.1-RC1 sparc64
>>>>>>> 19:25 Tue 18-Apr seanbloody
[~] 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+AJ91hNZ1duFYmjDe3aLABE2JuE6f9ACd
HOHc
jKzltWxtLNdMXkEp0Ck1n4Y=
=hnK1
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"