From owner-freebsd-emulation@FreeBSD.ORG Sat Oct 31 15:50:05 2009 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64745106568B for ; Sat, 31 Oct 2009 15:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 486408FC18 for ; Sat, 31 Oct 2009 15:50:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9VFo5cv017687 for ; Sat, 31 Oct 2009 15:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9VFo57R017686; Sat, 31 Oct 2009 15:50:05 GMT (envelope-from gnats) Date: Sat, 31 Oct 2009 15:50:05 GMT Message-Id: <200910311550.n9VFo57R017686@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Alexander Best Cc: Subject: Re: kern/133144: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:50:05 -0000 The following reply was made to PR kern/133144; it has been noted by GNATS. From: Alexander Best To: , Cc: Subject: Re: kern/133144: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 Date: Sat, 31 Oct 2009 16:48:33 +0100 (CET) it took some time to entirely identify the cause of the problems reported in this PR. please disregard all previous comments trying to describe problem! they merely dealt with symptoms and not the actual cause! they're superseded by this comment! 1. although the problem report deals with a segfault related to a linux lib supplied with the nvidia closed source freebsd driver the problem isn't limited to this specific linux lib. 2. the problem should occur with any linux binary/lib which was built under/for a linux version which uses one of the old linux threading models. this comment from http://wiki.freebsd.org/linux-kernel provides a short description of the problem: "Linux has gone through two threading model changes. If a Linux application or library has been linked against the old pthreads without fast TLS support or pthreads with internal TLS support libraries it will segfault." a detailed description of the threading situation under linux as well as under freebsd can be found in this thread: http://lists.freebsd.org/pipermail/freebsd-threads/2003-June/000530.html 3. the nvidia closed source drivers are no longer suffering from the problem described in this PR. the reason for that is that during installation of the driver an application is run which detects the linux kernel version. the application detects whether libnvidia-tls.so (old threading model) or libnvidia-tls.so (new threading model) needs to be installed. the old threading model is used on linux kernel < 2.6, the new one on >= 2.6. the symptoms described in this PR were caused by this libnvidia-tls.so the whole time and NOT by libGL.so (it's merely linked against libnvidia-tls.so). the following short statement by zander@nvidia.com is added as a reference: "the two libnvidia-tls libraries support different TLS models: the one currently shipped with the NVIDIA FreeBSD graphics driver supports the old-style TLS model, the tls/ one the new ELF TLS model. The crashes you were seeing were not due to a problem with the Linux emulation layer. Future NVIDIA FreeBSD graphics driver releases will automatically determine which library to install." 4. right now the only way to run linux bins/libs which got build against a linux kernel with an old threading model is to alter compat.linux.osrelease and revert to 2.4 linux emulation mode. 5. what needs to be done to solve this PR is to determine the threading model of a bin/lib and a) figure out a way to execute it under 2.6 linux emulation or b) issue a warning and abort execution. right now this PR should be considered a 2.6.26 emulation stopper and makes it impossible to remove 2.4.2 emulation legacy code since this would prevent certain bins/libs to run at all. alex