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