From owner-freebsd-bugs@FreeBSD.ORG Sat Jul 21 04:30:15 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 477A616A41A for ; Sat, 21 Jul 2007 04:30:15 +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 C6E1A13C45B for ; Sat, 21 Jul 2007 04:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6L4UEsC040761 for ; Sat, 21 Jul 2007 04:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6L4UECk040747; Sat, 21 Jul 2007 04:30:14 GMT (envelope-from gnats) Date: Sat, 21 Jul 2007 04:30:14 GMT Message-Id: <200707210430.l6L4UECk040747@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: vehemens Cc: Subject: Re: kern/114688: [drm] RADEON/AIGLX/DRM Problem X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vehemens List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 04:30:15 -0000 The following reply was made to PR kern/114688; it has been noted by GNATS. From: vehemens To: Stefan Sperling Cc: bug-followup@freebsd.org Subject: Re: kern/114688: [drm] RADEON/AIGLX/DRM Problem Date: Fri, 20 Jul 2007 21:21:53 -0700 On Friday 20 July 2007 03:17:05 am Stefan Sperling wrote: > > Why: Submitter disagrees that this PR is the same as the ones cited > > in the Audit-Trail. > > No, I believe vehemens said that only PR kern/89271 didn't apply, > not that both didn't apply. > > PR kern/112984 is indeed about the very same bug, yet this PR > (kern/114688) provides a much better analysis of the problem. PR kern/112984 and kern/114688 probably have the same root cause. The cards are different however. Also the locking problem may impact other drivers. > It explains why the "fix" provided in kern/112984 is likely inadequate. > Note that the "fix" supposed in kern/112984 is just patches by vehemens, > who also opened this issue, ported blindly to FreeBSD 6.2 by myself > hoping that it would work. But it didn't. > > So I'd favour this issue over kern/112984, because it has more > valuable information. Maybe they should me merged? Is this possible > at all with GNATS? > > I'd really like to see this fixed, but I have no clue about the > subsystems involved either. Without knowing how these subsystems > are supposed to interact by design it's almost impossible to come > up with "the proper" fix. > > vehemens, are you still actively trying to find a fix for this issue? Still working it, but I think it's an architecture issue, and I don't have the knowledge to know which piece to fix, hence the writing of the PR. Here's my list of possible approaches: 1) The DRM driver counts open and closes, and only removes the lock on the last close. However it's not clear to me that the DRM driver would get the multiple closes needed if the xserver process terminated abnormally. Also according to the close man page "However, the semantics of System V and IEEE Std 1003.1-198 (``POSIX.1'') dictate that all fcntl(2) advisory record locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process." 2) Rewrite of libdrm to only probe once. 3) Modify the xserver to reacquire the lock before drawing.