Bug 214148

Summary:	"4gb seg fixup, process beagle-build-in" message on FC6 with Xen
Product:	[Fedora] Fedora	Reporter:	Răzvan Sandu <rsandu2004>
Component:	beagle	Assignee:	Alexander Larsson <alexl>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	russell, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-11-08 11:44:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Răzvan Sandu 2006-11-06 08:31:29 UTC

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 22:38:56 UTC

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 08:03:50 UTC

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 11:44:56 UTC

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 ***