Bug 214597 - 4gb seg fixup on many binaries -- something didn't upgrade?
4gb seg fixup on many binaries -- something didn't upgrade?
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-08 10:55 EST by Russell McOrmond
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.5-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-09 08:04:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russell McOrmond 2006-11-08 10:55:14 EST
Description of problem:

I am running FC5 xenU's under a FC5 xen0.  When I upgrade to the latest
kernel-xenU-2.6.18-1.2200.fc5  I am receiving a log of "4gb seg fixup" messages.
 I am aware that this is a warning telling me when things would be slower, and
not a bug in the kernel.

/etc/ld.so.conf.d/ has a number of "kernelcap-*.conf" files with the "hwcap 0
nosegneg" in it.

This is an FC5 based xen that was build from earlier FC4 based installes that
were on standalone machines.  It might be a library other than glibc that is the
source of the problem, and it might even be an older library that just needs to
have the revision number bumped so that it would be upgraded on people's
machines in a similar situation.

See notes below why I believe this to be the case for libtermcap-2.0.8-45 
libcap-1.10-24.2.i386.rpm

Some example messages in /var/log/messages after a boot into the latest kernel.

Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f3a06
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:08117bae
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f692d
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f693b
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f692d
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f693b
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:08120d22
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080a8501
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f692d
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f693b
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process hwclock (pid 195), cs:ip
73:00de71ae
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process udevd (pid 223), cs:ip
73:005ed43e
Nov  8 03:10:01 calcutta kernel: 4gb seg fixup, process ifup-eth (pid 678),
cs:ip 73:00bb743e
Nov  8 03:10:03 calcutta kernel: 4gb seg fixup, process xinetd (pid 906), cs:ip
73:002c9ee3
Nov  8 03:10:08 calcutta kernel: 4gb seg fixup, process crond (pid 1071), cs:ip
73:0026a43e
Nov  8 03:10:13 calcutta kernel: 4gb seg fixup, process httpd (pid 1098), cs:ip
73:0020743e
Nov  8 03:10:18 calcutta kernel: 4gb seg fixup, process httpd (pid 1099), cs:ip
73:0020743e
Nov  8 03:10:24 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:10:28 calcutta kernel: 4gb seg fixup, process tcsh (pid 1114), cs:ip
73:004b5246
Nov  8 03:10:33 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:10:38 calcutta kernel: 4gb seg fixup, process tcsh (pid 1114), cs:ip
73:0049f217
Nov  8 03:10:44 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:10:49 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:10:54 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:10:59 calcutta kernel: 4gb seg fixup, process httpd (pid 1098), cs:ip
73:0020c52f
Nov  8 03:11:04 calcutta kernel: 4gb seg fixup, process httpd (pid 1099), cs:ip
73:0020c52f
Nov  8 03:11:11 calcutta kernel: 4gb seg fixup, process httpd (pid 1101), cs:ip
73:0020c52f
Nov  8 03:11:16 calcutta kernel: 4gb seg fixup, process sendmail (pid 1052),
cs:ip 73:0057c52f
Nov  8 03:11:19 calcutta kernel: 4gb seg fixup, process httpd (pid 1103), cs:ip
73:0020c52f
Nov  8 03:11:24 calcutta kernel: 4gb seg fixup, process httpd (pid 1101), cs:ip
73:0020743e
Nov  8 03:11:30 calcutta kernel: 4gb seg fixup, process httpd (pid 1102), cs:ip
73:0020c52f
Nov  8 03:11:35 calcutta kernel: 4gb seg fixup, process sendmail (pid 1044),
cs:ip 73:00473946
Nov  8 03:11:40 calcutta kernel: 4gb seg fixup, process httpd (pid 1097), cs:ip
73:0020c52f
Nov  8 03:11:44 calcutta kernel: 4gb seg fixup, process httpd (pid 1098), cs:ip
73:00e596b8
Nov  8 03:11:49 calcutta kernel: 4gb seg fixup, process httpd (pid 1100), cs:ip
73:0020c52f
Nov  8 03:11:54 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:11:59 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:12:03 calcutta kernel: 4gb seg fixup, process python (pid 867), cs:ip
73:001ac43e
Nov  8 03:12:09 calcutta kernel: 4gb seg fixup, process httpd (pid 1101), cs:ip
73:00e596b8
Nov  8 03:12:14 calcutta kernel: 4gb seg fixup, process httpd (pid 1102), cs:ip
73:00e596b8
Nov  8 03:12:19 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:12:24 calcutta kernel: 4gb seg fixup, process sendmail (pid 1043),
cs:ip 73:004aa43e
Nov  8 03:12:29 calcutta kernel: 4gb seg fixup, process httpd (pid 1097), cs:ip
73:0020c52f
Nov  8 03:12:33 calcutta kernel: 4gb seg fixup, process python (pid 867), cs:ip
73:001ac43e
Nov  8 03:12:38 calcutta kernel: 4gb seg fixup, process httpd (pid 1100), cs:ip
73:00e596b8
Nov  8 03:12:44 calcutta kernel: 4gb seg fixup, process sendmail (pid 1148),
cs:ip 73:004af52f
Nov  8 03:12:51 calcutta kernel: 4gb seg fixup, process sendmail (pid 1044),
cs:ip 73:004aa43e
Nov  8 03:12:53 calcutta kernel: 4gb seg fixup, process mysqld (pid 1009), cs:ip
73:004ef43e
Nov  8 03:12:58 calcutta kernel: 4gb seg fixup, process httpd (pid 1100), cs:ip
73:0020c52f
Nov  8 03:13:03 calcutta kernel: 4gb seg fixup, process python (pid 867), cs:ip
73:001ac43e
Nov  8 03:13:09 calcutta kernel: 4gb seg fixup, process httpd (pid 1104), cs:ip
73:00e596b8
Nov  8 03:13:13 calcutta kernel: 4gb seg fixup, process sendmail (pid 1160),
cs:ip 73:004aa43e
Nov  8 03:13:18 calcutta kernel: 4gb seg fixup, process tcsh (pid 1114), cs:ip
73:0049f217
Nov  8 03:13:23 calcutta kernel: 4gb seg fixup, process K15httpd (pid 1259),
cs:ip 73:00cf243e


The last entry is a bash script.

# ldd /bin/bash
        linux-gate.so.1 =>  (0x00c38000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00b52000)
        libdl.so.2 => /lib/libdl.so.2 (0x00111000)
        libc.so.6 => /lib/libc.so.6 (0x009ff000)
        /lib/ld-linux.so.2 (0x00c39000)

# rpm -qf /lib/libtermcap.so.2 /lib/libdl.so.2 /lib/libc.so.6 /lib/ld-linux.so.2
libtermcap-2.0.8-45
glibc-2.4-11
glibc-2.4-11
glibc-2.4-11


I tried downloading the libtermcap again and forcing the install.  I then
rebooted into the new kernel and the shell script related warnings went away.

The glibc is definetely from the FC5 yum repository as it has recently updated.


Investigating 'nscd' lead me to re-install libcap-1.10-24.2.i386.rpm , and I
don't see nscd in the list of processes.

I am wondering if there is an easier way to figure out what libraries are
causing the problem.  To avoid similar problems for other people it might be
useful to bump the version numbers of some of the packages that were in common
between FC4 and FC5 to ensure that when people upgrade they get the updates.
Comment 1 Russell McOrmond 2006-11-08 13:31:48 EST
I don't know if the following makes any sense...

If I look at:

Nov  8 13:26:09 calcutta kernel: 4gb seg fixup, process sshd (pid 1110), cs:ip
73:009c143e

I'm assuming that the "009c143e" is an address in that process that has a problem.

If I go to /proc/1110/mem I see:

00960000-00a80000 r-xp 00000000 03:01 214171     /lib/libc-2.4.so

Am I wrong in guessing that the problem might still be in libc?

# rpm -qif /lib/libc-2.4.so
Name        : glibc                        Relocations: (not relocatable)
Version     : 2.4                               Vendor: Red Hat, Inc.
Release     : 11                            Build Date: Tue 12 Sep 2006 10:57:34
AM EDT
Install Date: Sun 17 Sep 2006 08:49:02 PM EDT      Build Host:
hs20-bc1-5.build.redhat.com
Group       : System Environment/Libraries   Source RPM: glibc-2.4-11.src.rpm
Size        : 10127877                         License: LGPL
Signature   : DSA/SHA1, Fri 15 Sep 2006 12:06:16 PM EDT, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : The GNU libc libraries.
Comment 2 Russell McOrmond 2006-11-08 13:56:37 EST
Sorry for replying to my own bugs.

It seems that I had the i386 version of glibc installed, and not the i686
version.  Installing the right glibc cleaned up many of the remaining problems.
 This may be something to just add to documentation.

Remaining warnings are much fewer.

Nov  8 13:45:12 calcutta kernel: 4gb seg fixup, process modprobe (pid 153),
cs:ip 73:080f693b
Nov  8 13:45:13 calcutta kernel: 4gb seg fixup, process nash (pid 490), cs:ip
73:080f3a06

Comment 3 Jakub Jelinek 2006-11-09 08:04:55 EST
Yeah, in FC5 only glibc.i686 had /lib/*/nosegneg/ libraries, in FC6 also
glibc.i386 as whole is -mno-tls-direct-seg-refs.
The remaining warnings are from statically linked binaries, only FC6 libc.a
and libpthread.a is built with -mno-tls-direct-seg-refs.
But even if FC5 libc.a was changed, you'd still need to relink all statically
linked programs.  In FC5 just use glibc.i686 and live with a few warnings
from statically linked programs or upgrade to FC6.

Note You need to log in before you can comment on or make changes to this bug.