Date: Tue, 24 Jul 2007 17:29:34 +0800 From: Ganbold <ganbold@micom.mng.net> To: vehemens <vehemens@verizon.net> Cc: freebsd-bugs@FreeBSD.org, stsp@stsp.name Subject: Re: kern/114688: [drm] RADEON/AIGLX/DRM Problem Message-ID: <46A5C67E.4050508@micom.mng.net> In-Reply-To: <200707210430.l6L4UECk040747@freefall.freebsd.org> References: <200707210430.l6L4UECk040747@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
vehemens wrote: > 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. > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > > > > Vehemens, any progress on this issue? I have Radeon X300 Series graphics card and I have some issues like problem with AIGLX, googleearth crashes X etc. If you find some solution please let me know. thanks, Ganbold -- pixel, n: A mischievous, magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology: Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A5C67E.4050508>