RE: NPTL/db4 problem with FC3

RE: NPTL/db4 problem with FC3

[Ian Pratt]

 > It turned out to be a FC specific db4 problem with non-NPTL-aware
> ARCHes:
> 
>   <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933>
> 
> Unfortunatly, RedHat closed this bug as WONTFIX, but it's 
> still present
> with FC3 on ARCH={xen,um}. /lib/tls and /usr/lib/tls moved away, the
> LD_ASSUME_KERNEL workaround does not help, too.

We have a trivial patch to NTPL glibc that make it "xen-friendly",
providing glibc is built with the "-mno-tls-direct-seg-refs" option to
gcc.

It's currently undergoing testing, and I expect we'll check it in to the
repo later this week.

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: NPTL/db4 problem with FC3

[Nils Toedtmann]

Am Dienstag, den 22.03.2005, 16:27 +1200 schrieb Peter: 
> (Me Too ++: I'm running into the same issues with a non-nptl DB4 and rpm 
> on rhel4)
> 
> And making it even more interesting:
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-x86/
> 
> "Red Hat Enterprise Linux 5 will no longer include support for 
> LinuxThreads. Therefore, applications that require LinuxThreads support 
> must be updated before they will be able to work properly on a Red Hat 
> Enterprise Linux 5 system."
> 
> I would appreciate a description of what needs to be done in order for 
> xen or UML to support the use of nptl inside the guest server.  And any 
> info on progress towards trying to support it.

Me too


Am Montag, den 21.03.2005, 21:34 +0000 schrieb Ian Pratt:
> > It turned out to be a FC specific db4 problem with non-NPTL-aware
> > ARCHes:
> > 
> >   <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933>
> > 
> > Unfortunatly, RedHat closed this bug as WONTFIX, but it's 
> > still present
> > with FC3 on ARCH={xen,um}. /lib/tls and /usr/lib/tls moved away, the
> > LD_ASSUME_KERNEL workaround does not help, too.
> 
> We have a trivial patch to NTPL glibc that make it "xen-friendly",
> providing glibc is built with the "-mno-tls-direct-seg-refs" option to
> gcc.
> 
> It's currently undergoing testing, and I expect we'll check it in to the
> repo later this week.

I will test that, but as long as distros do not patch their glibc, too,
we are in the same sitiuation as i am with my db4-hack: i have to
rebuild a central package which is tricky to compile. I have to do that
each time the package is updated. Apt/yum shall not update it to newly
released versions (only from my own repository, resp.), so i have to lie
about the version number or i have to rename it (db4 ==> db4-xen). Try
to replace db4-4.2.52 with db4-xen-4.2.52 on a running system ... that's
really UGLY.

Does anybody know if & how RedHat solved that problem on FC4test1 (which
is shipping with xen-unstable & cyrus-imapd)?

/nils.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: NPTL/db4 problem with FC3

[Tupshin Harper]

Ian Pratt wrote:

>
>We have a trivial patch to NTPL glibc that make it "xen-friendly",
>providing glibc is built with the "-mno-tls-direct-seg-refs" option to
>gcc.
>
>It's currently undergoing testing, and I expect we'll check it in to the
>repo later this week.
>
>Ian
>
>  
>
How's this patch coming. I'm trying to get a gentoo domU going and I 
would love to give this a try.

-Tupshin


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: NPTL/db4 problem with FC3

[Nils Toedtmann]

Am Montag, den 21.03.2005, 21:34 +0000 schrieb Ian Pratt:
>  > It turned out to be a FC specific db4 problem with non-NPTL-aware
> > ARCHes:
> > 
> >   <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933>
> > 
> > Unfortunatly, RedHat closed this bug as WONTFIX, but it's 
> > still present
> > with FC3 on ARCH={xen,um}. /lib/tls and /usr/lib/tls moved away, the
> > LD_ASSUME_KERNEL workaround does not help, too.
> 
> We have a trivial patch to NTPL glibc that make it "xen-friendly",
> providing glibc is built with the "-mno-tls-direct-seg-refs" option to
> gcc.
> 
> It's currently undergoing testing, and I expect we'll check it in to the
> repo later this week.

Hi, 

is the patch available now? I'd like to try it. CentOS suffers from the
same bug. Will that patch obsolete moving /lib/tls/?

BTW: FC3 & CentOS have db4 libs within /usr/lib/tls/. Do i have to move
that, too?

/nils.

RE: NPTL/db4 problem with FC3

[Rik van Riel]

On Mon, 4 Apr 2005, Nils Toedtmann wrote:

> is the patch available now? I'd like to try it. CentOS suffers from the 
> same bug. Will that patch obsolete moving /lib/tls/?
> 
> BTW: FC3 & CentOS have db4 libs within /usr/lib/tls/. Do i have to move 
> that, too?

You may want to keep them in place for FC3 and CentOS,
since db4 locking is only per-process without TLS !

With the segment flipping code, the only disadvantage
of having /lib/tls in place is performance - I have
not seen any stability problems.

Ian, would it be an idea to change the big WARNING to
print something else ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: NPTL/db4 problem with FC3

[Keir Fraser]

On 4 Apr 2005, at 20:55, Rik van Riel wrote:

> Ian, would it be an idea to change the big WARNING to
> print something else ?

We could certainly remove the stability warning. Is that sufficient?

  -- Keir

Re: NPTL/db4 problem with FC3

[Rik van Riel]

On Mon, 4 Apr 2005, Keir Fraser wrote:
> On 4 Apr 2005, at 20:55, Rik van Riel wrote:
> 
> > Ian, would it be an idea to change the big WARNING to
> > print something else ?
> 
> We could certainly remove the stability warning. Is that sufficient?

Yes, something like the following should be fine:

***************************************************************
***************************************************************
** WARNING: Currently emulating unsupported memory accesses  **
**          in /lib/tls libraries. The emulation is very     **
**          slow.  To ensure full performance, you should    **
**          execute the following as root:                   **
**          mv /lib/tls /lib/tls.disabled                    **
***************************************************************
***************************************************************


-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: NPTL/db4 problem with FC3

[Nils Toedtmann]

Sorry for being insistent, but what about that "trivial patch to NTPL
glibc" you told me about?

/nils.

RE: NPTL/db4 problem with FC3

[Ian Pratt]

> Sorry for being insistent, but what about that "trivial patch 
> to NTPL glibc" you told me about?

Christian's away -- he'll check it in when he's back.
You also need to build glibc (and ideally any other binaries that use
tls) with:
  "-mno-tls-direct-seg-refs"

Ian

RE: NPTL/db4 problem with FC3

[Nils Toedtmann]

Am Dienstag, den 05.04.2005, 12:51 +0100 schrieb Ian Pratt:
> > Sorry for being insistent, but what about that "trivial patch 
> > to NTPL glibc" you told me about?
> 
> Christian's away -- he'll check it in when he's back.
> You also need to build glibc (and ideally any other binaries that use
> tls) with:
>   "-mno-tls-direct-seg-refs"

Reminder ... /nils.

Re: NPTL/db4 problem with FC3

[Kip Macy]

Ian is away for the weekend.



On 4/16/05, Nils Toedtmann <xen-devel@nils.toedtmann.net> wrote:
> Am Dienstag, den 05.04.2005, 12:51 +0100 schrieb Ian Pratt:
> > > Sorry for being insistent, but what about that "trivial patch
> > > to NTPL glibc" you told me about?
> >
> > Christian's away -- he'll check it in when he's back.
> > You also need to build glibc (and ideally any other binaries that use
> > tls) with:
> >   "-mno-tls-direct-seg-refs"
> 
> Reminder ... /nils.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

NPTL/db4 problem with FC3

[Nils Toedtmann]

This is a cross post to <xen-devel@lists.sourceforge.net> and <user-
mode-linux-user@lists.sourceforge.net>


Dear lists,

Anybody successfully running cyrus-imapd in FC2/3+Xen/UML? When i tried
to run cyrus-imapd in a virtual FC3 (Xen or UML) i got lot's of

  DBERROR db4: Berkeley DB library configured to support only
               DB_PRIVATE environments
  DBERROR: dbenv->open '/var/lib/imap/db' failed: Invalid argument
  DBERROR: init() on berkeley

It turned out to be a FC specific db4 problem with non-NPTL-aware
ARCHes:

  <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933>

Unfortunatly, RedHat closed this bug as WONTFIX, but it's still present
with FC3 on ARCH={xen,um}. /lib/tls and /usr/lib/tls moved away, the
LD_ASSUME_KERNEL workaround does not help, too.

So i followed the way of Radu Greab and rebuilt db4 using his patches
and specfile

  <https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=100060>

It was tricky, but worked. As this is an ugly workaround (eg it bombs
with apt/yum updating) i look for a better solution. 

Anybody?

/nils.
--
no sig



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click