Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#4743 - new glibc does not coexist well with Xen

Attached to Project: Arch Linux
Opened by Tom Dobes (tdobes) - Tuesday, 30 May 2006, 23:44 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 31 May 2006, 05:31 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Jan de Groot (JGC)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm running Arch on a Unixshell VPS. After upgrading to the latest glibc in testing (2.4-2), I am receiving an error regarding /lib/tls from Xen when the system boots. I'm running kernel 2.6.16.13-xenU.

In the past, I was able to work around this by building a custom version of glibc with some Xen-specific patches applied. When Arch recently upgraded to glibc 2.3.6, these were included with glibc, but were in /lib/tls.nosegneg. At the time, I remember someone mentioning that the Xen-friendly versions were supposed to be auto-selected, but that never worked for me. Instead, I simply removed the stock /lib/tls and put /lib/tls.nosegneg in its place.

Anyway, my problem is that there is no longer a /lib/tls OR a /lib/tls.nosegneg. Is this new glibc supposed to deal with Xen itself? or is Arch dropping Xen support, meaning I should go back to building a custom glibc version myself?

Here's the error I get when the system boots:
***************************************************************
***************************************************************
** WARNING: Currently emulating unsupported memory accesses **
** in /lib/tls glibc libraries. The emulation is **
** slow. To ensure full performance you should **
** install a 'xen-friendly' (nosegneg) version of **
** the library, or disable tls support by executing **
** the following as root: **
** mv /lib/tls /lib/tls.disabled **
** Offending process: init (pid=1) **
***************************************************************
***************************************************************
This task depends upon

Closed by  Jan de Groot (JGC)
Tuesday, 06 June 2006, 20:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  Install glibc-xen from extra (testing at this moment), this will add some Xen-capable glibc libraries in /lib/nosegneg, which are used when the kernel exports nosegneg hwcap. For more info, see this patch:

http://lkml.org/lkml/2006/5/9/78
Comment by Tom Dobes (tdobes) - Tuesday, 30 May 2006, 23:46 GMT
BTW: I believe we're running Xen 3.0.2
Comment by Jan de Groot (JGC) - Wednesday, 31 May 2006, 06:13 GMT
Xen should expose a nosegneg hwcap, so the linker from glibc should select a Xen-specific glibc in /lib/nosegneg.

Since we don't include any Xen support in the whole distribution, I wrecked out the extra build pass in glibc. Xen runs "fine" with the stock glibc, but for better performance a customized glibc-xen is required.

I haven't had the time to create such a package, a package will be available shortly.

Loading...