[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] xen-friendly glibc


  • To: <echo@xxxxxxxxxxxx>
  • From: "Geetha, ANGLER - EIT" <geetha@xxxxxxxxxxxxxxx>
  • Date: Thu, 7 Aug 2008 11:22:33 +0530
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 06 Aug 2008 22:53:15 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: Acj3j/VQRmcHVeWuT0eg8gts2qpmNQAwNGWw
  • Thread-topic: [Xen-users] xen-friendly glibc

Thanks for your timely response Tim, It is very helpful for all
slackware xen users.

I am using slackware 12.0 and glibc version is 2.5.

I bit of scared abot this issue, but I clear now from your explanation,
but i have to disable this warning :) so i doing research on this..

Please help me..

Can you give me the url for Xen-friendly glibc for slackware?

Thanks & Regards
Sg..



On Wed, 2008-08-06 at 12:27 +0530, Geetha, ANGLER - EIT wrote:
>  Thanks for your response Tim.
> 
> Is there xen friendly glibc available for Slackware?

Yikes! It has been a while since I've used Slackware. What version of
libc is the guest using, exactly?

I really would not worry about the warning, unless its just something
fun for you to study and solve. Its really quite harmless.

This is really trivial. Your init is statically linked against the libc
used to when compiling it (thus making said libc a part of the program
vs using shared objects). Unless you need to reduce boot time by a few
seconds I really recommend just ignoring it.

If you have disabled tls for dynamically linked programs (as you
indicated that you have) its really a non issue.

If some threading server throws the same warning, its cause for concern
because its also likely statically linked (I doubt that you'd ever see
that).

A few of the core utilities _might_ produce that warning, don't worry
until you see some threading service issue the same.

I hope that this helps.

Cheers!
--Tim

> 
> Already Xen running on remote server, i have created  instance for my
> slackware guest os on it and uploaded on it..
> 
> While booting slackware guest getting this warning.. 
> 
> Regards,
> Sg..
> 
> 
> 
> -----Original Message-----
> From: Tim Post [mailto:echo@xxxxxxxxxxxx] 
> Sent: Wednesday, August 06, 2008 12:10 PM
> To: Geetha, ANGLER - EIT
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] xen-friendly glibc
> 
> On Wed, 2008-08-06 at 09:19 +0530, Geetha, ANGLER - EIT wrote:
> 
> > ***************************************************************
> > ***************************************************************
> > 
> >               * WARNING: Currently emulating unsupported memory
> >                 accesses **
> >               * in /lib/tls glibc libraries. The emulation is **
> >               * slow. To ensure full performance you should **
> >               * install a 'xen-friendly' (nosegneg) version of **
> >               * the library, or disable tls support by executing **
> >               * the following as root: **
> >               * mv /lib/tls /lib/tls.disabled **
> >               * Offending process: init (pid=1) **
> > ***************************************************************
> > ***************************************************************
> > 
> > I have rebuilt the glibc with "-mno-tls-direct-seg-refs" option and 
> > installed it then sysvinit, mdadm packages
> > 
> > but still getting same warning. 
> 
> This is because init was compiled and statically linked without xen
> friendly libc. Its perfectly harmless and can be ignored.
> 
> If you want to make the warning go away, obtain the source to init
> (sysvinit) from your distro and rebuild/install it after installing
xen
> friendly glibc.
> 
> Its quite harmless and really not worth fixing. 
> 
> Cheers,
> --Tim
> 
> 
> --
> Monkey + Typewriter = Echoreply ( http://echoreply.us )
> 
-- 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.