Date: Sat, 21 Jul 2007 04:30:14 GMT From: vehemens <vehemens@verizon.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/114688: [drm] RADEON/AIGLX/DRM Problem Message-ID: <200707210430.l6L4UECk040747@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/114688; it has been noted by GNATS. From: vehemens <vehemens@verizon.net> To: Stefan Sperling <stsp@stsp.name> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707210430.l6L4UECk040747>