Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 7733 - Request for IBM NGPT support during Gentoo system build
Summary: Request for IBM NGPT support during Gentoo system build
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
URL: http://www-124.ibm.com
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-09-10 04:01 UTC by Curtis Hogg
Modified: 2003-08-07 08:17 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
glibc-2.2.5-r6.ebuild (glibc-2.2.5-r6.ebuild,7.08 KB, text/plain)
2002-09-23 17:10 UTC, Martin Schlemmer (RETIRED)
Details
glibc-2.2.5-r6.ebuild (glibc-2.2.5-r6.ebuild,9.38 KB, text/plain)
2002-09-24 12:33 UTC, Martin Schlemmer (RETIRED)
Details
glibc-2.2.5-r6.ebuild (glibc-2.2.5-r6.ebuild,9.59 KB, text/plain)
2002-09-29 13:24 UTC, Martin Schlemmer (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis Hogg 2002-09-10 04:01:55 UTC
The IBM Next-Generation POSIX Threading library is an LGPL POSIX threading library that implements a M:N threading model. This library brings Linux much closer to POSIX compliance where threading is concerned, and brings with it better performance. I would like to see use of NGPT added as an option during the Gentoo Linux stage1 build process, so all applications can be compiled to take advantage of this threading model. The kernel patches required to support NGPT have already been accepted into the 2.5 development tree as well as 2.4, as of 2.4.19-pre2
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-11 13:10:17 UTC
Just me, or they not in official 2.4.19 ?  Also, last time I checked,
nextgen threads broke some stuff.  We did talk about this some time
back (6 months ??), and will support it, but it needs a wider acceptance
first (should definately be in 2.4 kernel for one).

Comment 2 Curtis Hogg 2002-09-11 13:22:09 UTC
Quoted from IBM's website:
Kernel release 2.4.19 contains everything necessary to run NGPT and use of the
patch is not required.

and

If you're running 2.4.19, apply the
  the patch-futex-2.4.19 patch.  This patch only contains the extensions
necessary for
  run NGPT 2.0 (the release of the kernel provides all the other necessary NGPT
support
  by default, so a smaller patch is appropriate).

NGPT has come a long way since 6 months ago. And as of 2.4.19pre2, the basic
hooks for NGPT support *were* added into the 2.4 tree. NGPT 2.0 has some new
extensions that haven't been added yet, but they probably will be for 2.4.20. 
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-11 15:39:10 UTC
Ok, so I havent maybe really checked it out again :=)

I still think to maintain stability, we should wait a bit, as something like
this will need assurance that the kernel can handle it.

Also, we are on a feature freeze for 1.4_rc release.
Comment 4 Curtis Hogg 2002-09-11 17:11:30 UTC
I can understand that, a change so late in 1.4's devel would be folly. Perhaps
for 1.5? And I can also understand the need for stability, which is why I just
wanted it to be something like a USE flag during bootstrapping, for people who
decided they'd take the risk and try it. At bootstrap is the best time to add
NGPT cause then all the applications compiled for the system will take advantage
of it, and there won't be problems with applications that were linked against
linuxthreads.
Comment 5 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-11 18:08:18 UTC
Thanks.

Anyhow, I will see what I can do, as I wanted to try it out myself back
then, but never got to it.  Will not promise though, as I have my hands
a bit full at the moment.  After 1.4, I am sure we can really make a 
plan.
Comment 6 Michael Cohen (RETIRED) gentoo-dev 2002-09-20 08:40:04 UTC
I gave it a shot, and most pthreads-enabled apps won't compile with it...

We need to have patches for NGPT support before we can use it. I can put 
futexes in the kernel though.
Comment 7 Michael Cohen (RETIRED) gentoo-dev 2002-09-23 08:51:22 UTC
on second thought, I realized that my problems were user error. it seems to 
work now.  Fast!
Comment 8 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-23 17:10:01 UTC
Created attachment 4110 [details]
glibc-2.2.5-r6.ebuild

Ok, this *should* be a ebuild which added NGPT support.

Some NOTES:

1) It is not a 100% drop in replacement for linuxthreads, so you still
   have to compile glibc with linuxthreads.  I just tweaked it to already
   install ngpt to /lib

2) I don't think that you should install it, except during bootstrap (from
   scratch ..) .. segfaults, etc

3) If bootstrap, you need a NGPT enabled kernel on bootcd, or system with
   booted with a NGPT enabled kernel.

4) When doing the chroot, you have to do an additional 'mount --bind':

    # mount --bind /dev/shm /mnt/gentoo/dev/shm

5) When starting bootstrap, you have to do:

    # export FEATURES=-sandbox ; export USE=ngpt

   I suggest to also put that in make.conf.


Like you would have noticed, I disable sandbox, as it once again is the
root of all evil :(  For some reason it causes things to segfault, although
not all the time, and also at relatively consistant places.
Comment 9 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-24 12:33:37 UTC
Created attachment 4138 [details]
glibc-2.2.5-r6.ebuild

Ok, this is what I think we want.  Basically this replaces linuxthreads
totally with NGPT.  Although we still need linuxthreads to get glibc to
compile, even glibc links against libpthread from NGPT!

Currently im busy with a 'emerge gnome' in a 100% NGPT chroot.	To get
it to work is the real hairy part, as most things that is linked against
the old glibc with linuxthreads seems to 'hang' when we merge this glibc.

I thus had to create a build image that is 90%-99% statically linked, and
then start a bootstrap chrooted from there.

Quick overview:

1) Create the static build image we are going to chroot into:

  # export ROOT=/var/tmp/build
  # FEATURES=-sandbox \
    LDFLAGS=-static \
    USE="ngpt -X -gnome -gtk -tcltk" \
    emerge --nodeps --noreplace `/usr/portage/scripts/build.sh x86-1.4`

  Some stuff here like python needed attention.  For instance python I merged
  without the 'LDFLAGS=-static'.

2) Now we need to cleanout /var/tmp/build/var/db/pkg/ a bit.  We
   only want entries for:

     sys-kernel/linux-headers*
     sys-devel/binutils*
     sys-apps/baselayout*
     sys-libs/glibc*

  Very much like the secound build fase of creating stage1...

3) Chroot it, and do the normal 'source /etc/profile && env-update'

4) Fix the two things that either links to old libpthread, or should not
   be static:

  # FEATURES=-sandbox USE=build emerge --nodeps python bash

  NOTE: I had to use bash-2.05a here, as 2.05b needs autoconf ...

5) Do the bootstrap and emerge system.	Note the following:

  a) You need to have "ngpt" in your USE.  I created my own bootstrap.sh
     for this.

  b) Know that sandbox is going to bork.

  # export FEATURES=-sandbox
  # export USE=ngpt
  # /usr/portage/scripts/bootstrap.sh && emerge system

Well, that is roughtly it.  There is one or two other places build
broke for me.  I had to remerge db1 and db3 before perl worked for
instance ...
Comment 10 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-24 13:09:19 UTC
Another note:  '-pipe' in CFLAGS or CXXFLAGS can also cause issues...
Comment 11 Michael Cohen (RETIRED) gentoo-dev 2002-09-24 19:36:46 UTC
someone forgot to add "addwrite /dev/shm/ngpt" to that ebuild..
Comment 12 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-29 13:23:34 UTC
Comment #10 from me .. disgard as I was on crack or something.  As for comment 
#11, support have already been added to sandbox.

Update:

Most things seem to work fine with good performance, but the following
issues occured/remain:

1) NGPT-2.0.2 caused make to "hang" if -j2 or greater was used.  This is
   fixed in version 2.0.3.  Compiling 'make' static also fixed this with 2.0.2.

2) db-3.2.9 compiles with unresolved symbols if anything linked dinamically to
   it do not link in libpthread, or if db itself was not compiled with
   LDFLAGS="-lpthread".  Dont know how good an idea the second option is
   though.

3) Anything linked to librt.so.1 from glibc segfaults inside sandbox.

4) Anything that links dynamically to libGL* from nvidia-glx segfaults or
   "hangs".  MPlayer for instance segfaults, while gliv, xmms and glxgears
   "hangs".  If I delete the OpenGL plugins from xmms, it starts until the
   GUI appears, but then "hangs" again.

5) gcc-2.95.3 just do not compile.

Anything that shows the "hang" symptoms have a lot of nanosleep() calls in
the strace output.

In general install seems to be ok now.  You can do a normal bootstrap with
this changed glibc ebuild and "ngpt" in use.
Comment 13 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-29 13:24:33 UTC
Created attachment 4301 [details]
glibc-2.2.5-r6.ebuild

Latest ebuild just for completeness.
Comment 14 Stefan Jones (RETIRED) gentoo-dev 2002-10-08 05:52:49 UTC
I have tested, expensivily, ngpt with glibc-2.3 and the current version, 2.0.3,
is not compatable with glibc-2.3. All programs using ngpt segfault on startup.

I have sucessfully used ngpt with glibc-2.2.5 so it is not user error.

On the topic, it seems the offical new (beta) threading library for glibc and
linux is nptl 0.3, see
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00080.html and 
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00160.html for more info.

Should we use this instead when linux-2.6 is out?
Comment 15 Martin Schlemmer (RETIRED) gentoo-dev 2002-10-12 13:46:51 UTC
To be honest .. I think ill wait for linuxthreads2 :/
Comment 16 Stefan Jones (RETIRED) gentoo-dev 2003-01-06 08:17:57 UTC
Well I have been playing with nptl / linuxthreads2 for some time now, at the
request of woodchip.
It works very well with the 2.5.5x kernels. I have it installed on my desktop.

Version 0.15 nptl is complete, according to the author, for x86. You also need
the CVS version of glibc, which also is stable.

Redhat has already taken the step of putting it into there beta, rawhide,
distributions. We cannot be out done!

The only problem is the kernel requirement. Redhat has back ported the thread
changes to 2.4.20/21. The patch is fairly messy because it goes onto of a few
other redhat patches.

But I have completed patching 2.4.21-pre2 with o1-scheduler and the thread
backport. The kernel now needs to be debuged by me, but it should be ok.

What do you people think, would gentoo be interested, or do we wait for the
official 2.6 kernel + glibc ( which could be a while yet) eventhough we can have
it sooner.
Comment 17 Martin Schlemmer (RETIRED) gentoo-dev 2003-01-07 16:11:55 UTC
I havent tried NGPT, bug I have an cvs ebuild for glibc here, with NPTL (cvs).
It worked fine up to a week ago, but now anything using pthreads from NPTL
segfaults.  This was after a  cvs update.  Running 2.5.5[34] here btw.

Stephan, if the 2.4 patches are stable, I do not see why not, if 2.3.2 hits
the shelfs, but I think we need to test it first.  According from what I can
see from Redhats .spec's, they only consider NPTL stable/working for i686/athlon
archs.
Comment 18 Curtis Hogg 2003-01-07 21:12:16 UTC
I had a similar problem when I tried a much older version... As I recall, my
initial idea behind getting NGPT support into Gentoo was as a stageX compile
option, but not default. something like a USE flag, with a warning that not
everything may love it. Though, I'd love to see Gentoo adopt it as default. I
haven't read much on linuxthreads2 though. I may have to go look at it.
Comment 19 Stefan Jones (RETIRED) gentoo-dev 2003-01-08 01:50:33 UTC
At the moment nptl only exists for x86, it still has to be ported to other
archs. So this for the time being will be x86 only. I think some archs will not
be ported for some time (sparc + alpha)

The trick to get nptl to compile is to use the glibc CVS on the day of the nptl
release, ie for nptl-0.15 use cvs co -D "2003-01-05T20:19:00+0000" libc This is
the version I use, it works fine, except for nvidia's libGL binaries.

The kernel needs quite a bit of debuging, Ingo Molnar at redhat is working at
it. My patched 2.4.21 kernel causes old glibc linuxthreads aplications to
segfault. I have an idea where the problem is, will try to fix. The kernel runs
nptl fine though.
Comment 20 Alex Veber 2003-01-16 10:59:05 UTC
Martin, Stefan
Can you please post/email me your nptl ebuilds?
I REALLY want to test it!
Comment 21 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-07 08:17:23 UTC
NGPT is at end of life - we have NPTL ebuilds that works.