Summary: | savage problem: glxgears produce black window - locking problems with DRIClipNotify | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Massimiliano Mirabello <massimiliano.mirabello> | ||||||||||||||||||
Component: | General | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||
Severity: | normal | ||||||||||||||||||||
Priority: | high | CC: | pachoramos1, pascal.sclafer | ||||||||||||||||||
Version: | XOrg git | ||||||||||||||||||||
Hardware: | x86 (IA32) | ||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||
Bug Depends on: | |||||||||||||||||||||
Bug Blocks: | 6666 | ||||||||||||||||||||
Attachments: |
|
Description
Massimiliano Mirabello
2006-03-23 04:46:54 UTC
A little update. I tried latest snapshot and common libraries (20060324). Now X won't start and gives a black screen. With previows common libraries (20060311) glxgears gives always a little black screen (and 99% CPU usage). Created attachment 5080 [details]
Xorg.log with common-20060311
Created attachment 5081 [details]
Xorg.log with common-20060324
Created attachment 5082 [details]
Latest Kernel configuration
Created attachment 5083 [details]
Latest Xorg configuration
I have the same problem w/Fedora Core development on an "IBM ThinkPad T23" (SuperSavage/IXC 64). This does not mean however, that "DRI" is not working. "GL" screensavers work, so does "ppracer". I've got this problem too. I think it's related to the problem with Xorg 7.1 and the apparent problems this version has with the nvidia and ati drivers - might be graphics in general. I've got a Targa Visionary 1600 laptop, which has a "VGA compatible controller: S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA Controller (TwisterK) (rev 01)" according to lspci I'm a gentoo user, with kernel 2.6.16 I have the following packages (installed by portage): x11-drivers/xf86-video-savage 2.1.1 media-libs/mesa 6.5 x11-apps/mesa-progs 6.5 x11-base/xorg-x11 7.1 x11-base/xorg-server 1.1.0 Programs like Dosbox and scummvm seem to work still, but glxgears displays a black window, and an opengl game that I'm making (that does not use the SDL) creates a window, but doesn't ever draw to it, so you can still see the window underneath (or what was there before the window appeared). Hi, I can second this bug. My box is a portable HP OmniBook XE3 with a S3 Inc. 86C270-294 Savage/IX-MV (rev 13) running (all plain vanilla packaged) Ubuntu 6.06 with available updates as of 2006-06-17. A little more detail: Device: 5333:8c12 X.org: 7.0.0 Kernel: 2.6.15 The reason why people are reporting this bug with their 3D is because (at least it suspect so) 3D support is new in the driver for the affected cards. Out of the box this problem is worse that having no support for 3D at all of course, as software rendering worked for the affected cards. I realize there is not much joy or power in this chip anymore, and this box is being used primarily for productivity anyway, so it's not a big deal. If you need more info I will be available for this bug until august, when my work here is done and I no longer have access to the computer :). Cheers, Johan Ehnberg johan at ehnberg dot net I'm not able to reproduce the problem. You might try some combination of the following options and see if they help: Option "BusType" "PCI" Option "DmaMode" "None" Option "AGPMode" "2" # or 4 depending on what the max speed you chip supports You also may want to try the latest drm from drm cvs. (In reply to comment #9) None of your suggestions brings any improvement. I am running Fedora rawhide, and here, the kernel modules are already at their latest versions. Furthermore, adding your suggested options to my "xorg.conf" has no effect. "Xorg" is version 7.1. The standard "xscreensaver" modules such as "juggler3d", etc. work flawlessly with hardware rendering, but when I launch "glxgears" or use "OpenDX", the respective windows is plain black, and CPU load jumps to 100%. However, nothing (visible) is ever rendered to the screen. The graphics chips is a "SuperSavage/IXC 64". Btw, the "composite" extension is not enabled. (In reply to comment #8) I cannot confirm this for an "IBM ThinkPd T23" and a "SuperSavage/IXC 64" chip which is very similar to the "Savage/IX-MV". When I boot from a "Ubuntu 6.06 LTS" live CD, hardware rendering is up and running without any hassle. At a resolution of 1024x768@16bpp, "glxgears" paces along nicely at 500 fps. The issue appeared in my case only with some RC of "Xorg" 7.1, not for "Xorg" 7.0.0 used by "Ubuntu 6.06 LTS". (In reply to comment #11) > (In reply to comment #8) > > I cannot confirm this for an "IBM ThinkPd T23" and a "SuperSavage/IXC 64" chip > which is very similar to the "Savage/IX-MV". When I boot from a "Ubuntu 6.06 > LTS" live CD, hardware rendering is up and running without any hassle. At a > resolution of 1024x768@16bpp, "glxgears" paces along nicely at 500 fps. The > issue appeared in my case only with some RC of "Xorg" 7.1, not for "Xorg" 7.0.0 > used by "Ubuntu 6.06 LTS". I had no problems with Xorg 7.0 - This laptop didn't have linux installed on it before then. this problem has only emerged with the recent 7.1 release I've updated the Fedora bug for this issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196011 I've attempted a workaround for this issue and put it in an updated savage driver in rawhide, however it is completely untested as I do not have savage video hardware to test with. Fedora users, please test the new rawhide driver. Users of other distros can snag the src.rpm and rebuild with my patch, or grab everything from Fedora CVS. TIA can you please just attach the patch? Created attachment 6334 [details] [review] savage-disable-dri-bug196011.patch Sure.. here she be (completely untested) (In reply to comment #15) Come on, disabling "DRI" completely is not an acceptable suggestion. This is maybe admissible for fixing https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196011 as a distribution related patch in order to ensure the necessary reliability for upcoming FC6. Upstream "bugs.freedesktop.org" is the place to investigate the issue and to actually track down the bug. I recall that the current issue was not present in "Xorg 7.0". It is hence a mere regression with respect to a previous, working release. (In reply to comment #16) > (In reply to comment #15) > Come on, disabling "DRI" completely is not an acceptable suggestion. This is > maybe admissible for fixing > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196011 > > as a distribution related patch in order to ensure the necessary reliability for > upcoming FC6. Upstream "bugs.freedesktop.org" is the place to investigate the > issue and to actually track down the bug. There seems to be a misunderstanding here, so let me try to resolve it by explaining things, at least how I see it. The savage driver seems to have regressed at some point, and it appears that it was due to the integration of DRI support for newer hardware from the troubleshooting present in the linked Red Hat bug report and this one. Ultimately, the only "good" solution is for the savage driver to be fixed so that there are no problems with or without DRI on any hardware. Additionally, IMHO at least, the driver should "just work" by default on all hardware without requiring the end user to provide any special configuration options. That would be the ideal situation at least. Right now however, there is no real fix available yet, so it makes sense to provide users with a workaround if possible. Disabling DRI on the affected systems seems to work around the issue, so in order to have an out of the box working setup for /all/ Fedora users, it makes sense to disable DRI by default on the chips which have been reported to not work properly if DRI is enabled, until there is a better fix available. My untested patch intends to disable DRI by default on the chips that are known to not work right when it is enabled, and to allow users to forcibly re-enable DRI by configuration if desired. This patch was intended as a Fedora workaround until a newer savage driver is available upstream at X.Org which has resolved the problem. Since the problem isn't Fedora specific, and also since I'd like other people to test it who may or may not be using Fedora, I commented about my proposed workaround here to give others the opportunity to test it, and in case other distributions were interested in the workaround as well. Wether X.Org is interested in providing this workaround in the official savage driver or not does not matter to me. Personally I'd prefer to see a proper fix than have the workaround, but right now for Fedora at least we need a workaround until a proper fix is available. I only attached the patch here because Daniel asked me to. If I had written the patch with the intention of getting X.Org to include it in the official driver, I'd have attached the patch to the bug report initially, and explicitly asked for it to be committed to CVS. I didn't do that however, as that was not my intention. Hopefully this clarifies any misunderstanding you have now. > I recall that the current issue was not present in "Xorg 7.0". It is > hence a mere regression with respect to a previous, working release. Hopefully that will help those working on Savage DRI support to narrow down the problem and fix it in a future driver update. Once a fix is available, we can disable the Fedora workaround. I'm still interested in good/bad feedback from those affected by the problem as to wether the patch works right for them or not. It's in rawhide right now. Thanks in advance. very bad~~ can run Google Earth, 3d games... when i upgrade to last Ubuntu Edgy. S3 Graphics ProSavage DDR. may any nice man help improve this? TQ. ^O^ The bug comes from a lock on drawable acquirered in the function DRIClipNotify of the file dri.c from the X server. The lock is after that never released. And because of this lock the Mesa driver enters in a endless loop, for instance in DoBindContext of dri_util.c waiting for this lock to be released. The guilty modification has been done between the 1.16 and 1.17 revisions of dri.c . This change was trying to correct an ugly hack in the file dri.c A DRI guru should have a look on that, and help us to correct that issue. In a couple of day, I could propose a corrective patch, but I'm not sure of what I could do, because I have only a limited comprehension of the DRI system. (In reply to comment #19) > The bug comes from a lock on drawable acquirered in the function DRIClipNotify > of the file dri.c from the X server. The lock is after that never released. > And because of this lock the Mesa driver enters in a endless loop, for instance > in DoBindContext of dri_util.c waiting for this lock to be released. > > The guilty modification has been done between the 1.16 and 1.17 revisions of > dri.c . This change was trying to correct an ugly hack in the file dri.c > > A DRI guru should have a look on that, and help us to correct that issue. > > In a couple of day, I could propose a corrective patch, but I'm not sure of > what I could do, because I have only a limited comprehension of the DRI system. Does the DRI work if you disable AIGLX? ALso have you tried with the latest X server from git? There were some locking changes that might help. I'll try and look into this as well, but I'm not too familiar with the dri locking myself. Thanks for tracking this down. (In reply to comment #20) > (In reply to comment #19) > > The bug comes from a lock on drawable acquirered in the function DRIClipNotify > > of the file dri.c from the X server. The lock is after that never released. > > And because of this lock the Mesa driver enters in a endless loop, for instance > > in DoBindContext of dri_util.c waiting for this lock to be released. > > > > The guilty modification has been done between the 1.16 and 1.17 revisions of > > dri.c . This change was trying to correct an ugly hack in the file dri.c > > > > A DRI guru should have a look on that, and help us to correct that issue. > > > > In a couple of day, I could propose a corrective patch, but I'm not sure of > > what I could do, because I have only a limited comprehension of the DRI system. > > > Does the DRI work if you disable AIGLX? ALso have you tried with the latest X > server from git? There were some locking changes that might help. I'll try and > look into this as well, but I'm not too familiar with the dri locking myself. > Thanks for tracking this down. > i have disabled AIGLX, nothing changes!!! I found how to correct the bug. The SAREA drawable lock must be released in the BlockHandler overloaded by the savage DRI driver, as it is done in the original BlockHandler function. I post two patches to resolve the problem. They first apply on the xserver tree, and the second on the savage-driver tree. Created attachment 7035 [details] [review] DRI Patch Created attachment 7036 [details] [review] Savage Driver patch Created attachment 7041 [details] [review] not-working possible fix Ajax and I were discussing this on IRC today. Savage takes and releases the context lock in its wakeup and block handlers which screws up the ref counting and because it replaces the DRI's blockhandler chain, core blockhandler changes never make their way to the driver. the attached non-functioning patch based on ajax's is I think a step in the right direction, but something's still not right. (In reply to comment #22) > I found how to correct the bug. > The SAREA drawable lock must be released in the BlockHandler overloaded by the > savage DRI driver, as it is done in the original BlockHandler function. > I post two patches to resolve the problem. > They first apply on the xserver tree, and the second on the savage-driver tree. howto can i apply these patches? The patch proposed by Alex Deucher works fine. I tested it. I think, it is better to call the original block handler, instead of trying to copy its behaviour. I think, that this patch should be commited on the official driver. (In reply to comment #27) > The patch proposed by Alex Deucher works fine. I tested it. I think, it is > better to call the original block handler, instead of trying to copy its behaviour. > > I think, that this patch should be commited on the official driver. > > Hmmm... there may be other problems with the savage 3D driver in xorg 7.1 then... I'm still getting lockups. Perhaps it's an issue with my setup. I'll apply the patch soon. Thanks again for tracking this down! (In reply to comment #25) Great work! I have applied your patch to the current "Fedora rawhide" package "xorg-x11-drv-savage-2.1.1-5.fc6", and it works nicely. Finally, "glxgears" is back, and moreover, the patch also fixes https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196011 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 which means it kills 3 birds with one stone :) pushed to savage git master. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.