Currently emulating unsupported memory accesses warning for 10.04.01 on EC2 even with libc6-xen installed

W. Andrew Loe III andrew at andrewloe.com
Thu Nov 25 02:57:26 UTC 2010


I am seeing this warning in dmesg, but as far as I know it should not be there:

    7.223411]
[    7.223422]   ***************************************************************
[    7.223428]   ***************************************************************
[    7.223433]   ** WARNING: Currently emulating unsupported memory accesses  **
[    7.223438]   **          in /lib/tls glibc libraries. The emulation is    **
[    7.223443]   **          slow. To ensure full performance you should      **
[    7.223448]   **          install a 'xen-friendly' (nosegneg) version of   **
[    7.223453]   **          the library, or disable tls support by executing **
[    7.223458]   **          the following as root:                           **
[    7.223466]   **          mv /lib/tls /lib/tls.disabled                    **
[    7.223472]   ** Offending process: nginx (pid=980)                        **
[    7.223477]   ***************************************************************
[    7.223482]   ***************************************************************
[    7.223489]

I am running 10.04.1 on EC2. libc6-xen is installed,
/etc/ld.so.conf.d/xen.conf has the right options in it.

onehub at domU-12-31-39-07-4C-DB:~$ dpkg -l | grep libc6
ii  libc6                             2.11.1-0ubuntu7.5
 Embedded GNU C Library: Shared libraries
ii  libc6-dev                         2.11.1-0ubuntu7.5
 Embedded GNU C Library: Development Librarie
ii  libc6-xen                         2.11.1-0ubuntu7.5
 GNU C Library: Shared libraries [Xen version

onehub at domU-12-31-39-07-4C-DB:~$ cat /etc/ld.so.conf.d/xen.conf
# This directive teaches ldconfig to search in nosegneg subdirectories
# and cache the DSOs there with extra bit 1 set in their hwcap match
# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
# search in nosegneg subdirectories and to match this extra hwcap bit
# in the ld.so.cache file.
hwcap 1 nosegneg

Even if I actually move /lib/tls to /lib/tls.disabled, I still see
this error. I believe it is somewhere related to the Ruby Enterprise
Edition/Passenger/Nginx combination I have.

Ruby EE (a patched standard ruby interpreter with better Garbage
Collection) is from Phusion's site:
http://rubyenterpriseedition.com/download.html
Nginx package from my PPA: https://launchpad.net/~onehub/+archive/ppa/+packages

ldd indicates that all the binaries should be loading the right libraries:

onehub at domU-12-31-39-07-4C-DB:~$ ldd /usr/sbin/nginx
	linux-gate.so.1 =>  (0xb7884000)
	libcrypt.so.1 => /lib/tls/i686/nosegneg/libcrypt.so.1 (0xb7846000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7750000)
	libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0xb7737000)
	libpcre.so.3 => /lib/libpcre.so.3 (0xb7705000)
	libssl.so.0.9.8 => /lib/i686/cmov/libssl.so.0.9.8 (0xb76bd000)
	libcrypto.so.0.9.8 => /lib/i686/cmov/libcrypto.so.0.9.8 (0xb756b000)
	libz.so.1 => /lib/libz.so.1 (0xb7556000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7537000)
	libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0xb73d8000)
	libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0xb73b2000)
	/lib/ld-linux.so.2 (0xb7885000)
	libdl.so.2 => /lib/tls/i686/nosegneg/libdl.so.2 (0xb73ae000)

onehub at domU-12-31-39-07-4C-DB:~$ ldd
/usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/ext/nginx/HelperServer
	linux-gate.so.1 =>  (0xb7877000)
	libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0xb7852000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb775c000)
	libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0xb7736000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7716000)
	libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0xb75b8000)
	/lib/ld-linux.so.2 (0xb7878000)

onehub at domU-12-31-39-07-4C-DB:~$ ldd /usr/local/bin/ruby
	linux-gate.so.1 =>  (0xb77a9000)
	libtcmalloc_minimal.so.0 => /usr/local/lib/libtcmalloc_minimal.so.0
(0xb7771000)
	librt.so.1 => /lib/tls/i686/nosegneg/librt.so.1 (0xb7760000)
	libdl.so.2 => /lib/tls/i686/nosegneg/libdl.so.2 (0xb775c000)
	libcrypt.so.1 => /lib/tls/i686/nosegneg/libcrypt.so.1 (0xb7729000)
	libm.so.6 => /lib/tls/i686/nosegneg/libm.so.6 (0xb7703000)
	libc.so.6 => /lib/tls/i686/nosegneg/libc.so.6 (0xb75a5000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb74af000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7490000)
	libpthread.so.0 => /lib/tls/i686/nosegneg/libpthread.so.0 (0xb7476000)
	/lib/ld-linux.so.2 (0xb77aa000)

Suggestions, or ideas? Is this just a red herring? I can restart nginx
and I get no log messages. From some googling it looks like I should
be worried if I see "4gb seg fixup" in syslog, but I have none of
those and the performance is totally fine. Commands like convert from
ImageMagick execute quickly. I really don't like unexplained warnings.




More information about the ubuntu-server mailing list