Bug 214148 - "4gb seg fixup, process beagle-build-in" message on FC6 with Xen
"4gb seg fixup, process beagle-build-in" message on FC6 with Xen
Status: CLOSED DUPLICATE of bug 210001
Product: Fedora
Classification: Fedora
Component: beagle (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 03:31 EST by Răzvan Sandu
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-08 06:44:56 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 Răzvan Sandu 2006-11-06 03:31:29 EST
Description of problem:

On a stock FC6 with virtualization support installed (kernel, Xen, etc.), the
following message appears continuously after installation, "dirting" the screen:

4gb seg fixup, process beagle-build-in (pid 10967), cs:ip 73:0811cbff
(the last number, after, ":", is always variable)

The computer performs otherwise normally, except that the console is always
occupied by this continuous stream of messages, making almost impossible to
enter any command.

The message appears 30-40 times/minute.

The machine is a 1,6 MHz Pentium 4, 512 MB RAM, Intel motherboard.


Version-Release number of selected component (if applicable):

kernel-xen-2.6.18-1.2798.fc6
beagle-0.2.10-5.fc6
xen-3.0.3-0.1.rc3

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
The above message appears continuously.

Expected results:
The message shouldn't appear at all.

Additional info:
Comment 1 Stephen Tweedie 2006-11-06 17:38:56 EST
This message is highlighting bad behaviour by the beagle binary which is always
going to result in slow performance under Xen.

glibc on i386 uses a special segment register as a base for thread-local
storage.  But by default it accesses data both on from positive and negative
offsets of that register; that behaviour causes a kernel trap under Xen each
time it switches from positive to negative, as there is simply no way on x86
architecture to set up a segment register covering just user space that allows
both positive and negative offsets, and Xen requires that the register not cover
kernel space.

glibc has been updated to detect this case and avoid negative segment offsets
for Xen.  I don't know why beagle should be causing the same problem; is it
compiled with some old static library that does not know about nosegneg libraries?
Comment 2 Russell McOrmond 2006-11-08 03:03:50 EST
I've checked that I have a recent glibc, and it is configured with nosegneg. 
This is a FC5 xenU rather than a FC6, but I suspect there are similar issues.

  There is a huge number of processes that are showing these problems, more than
I think can be because of being statically linked.

Here are a few examples:

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

Comment 3 Alexander Larsson 2006-11-08 06:44:56 EST
A dup of bug 210001.
We did enable the "xen" mode in our mono which changes the way TLS is handled to
be xen-friendly (as seen in the bug). But it doesn't seem to help.


*** This bug has been marked as a duplicate of 210001 ***

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