Mike A. Harris wrote:
Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&...
There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away.
Perhaps these upstream CVS patches could be integrated into the Fedora Core patches. If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone.
John Thacker
søn, 26 02 2006 kl. 14:14 -0500, skrev John Thacker:
Mike A. Harris wrote:
Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&...
There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away.
Perhaps these upstream CVS patches could be integrated into the Fedora Core patches. If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone.
Mike, could we get a set of testing rpms akin to what you did with the fonts package to see if this fixes the r300 behavioral problems?
- David
David Nielsen wrote:
søn, 26 02 2006 kl. 14:14 -0500, skrev John Thacker:
Mike A. Harris wrote:
Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&...
There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away.
Perhaps these upstream CVS patches could be integrated into the Fedora Core patches. If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone.
Mike, could we get a set of testing rpms akin to what you did with the fonts package to see if this fixes the r300 behavioral problems?
Sure, check the Xorg sources/spec out of Fedora CVS, snag the patches from upstream CVS with cvs rdiff, apply them to the package, appending a custom identifier to the Release field such as: .dnielsen.1 to distinguish it from official Red Hat packaging, build new rpms and upload them to a custom yum repository. Might want to call it something like "David's Experimental X.org" or something to distinguish it.
That would provide a useful resource for the various people who would like to volunteer to help test and stabilize the r300 DRI support. It would also be a good idea to join the #dri-devel and #xorg-devel IRC channels on freenode, where most of the core developers frequent. That can be useful for realtime debugging discussion, etc. Another channel is #fedora-x, which I've been using for Fedora specific development/ packaging/maintenance discussion, but the other 2 channels are more useful for general issues.
Once you've got rpms ready, my recommendation would be to post an email to announce them to fedora-devel-list, fedora-test-list, and the main X.Org mailing list - xorg@lists.freedesktop.org
It's good to see more and more people volunteering to help out the X.Org project like this! It sure confirms the X.Org bazaar style development model was the right direction, over the closed development model of the previous X Window System implementation that was commonly shipped in the past.
Hi,
With the patches required to prevent the hangs, is DRI working fine for you?
As I previously reported (cf. DRI permission problem in this list), I'm getting "Operation not permitted" when trying to use DRI and libGL reverts back to (slow) indirect rendering with my ATI FireGL X1 (9700 chipset, r300 driver).
Cheers,
Émeric
Mike A. Harris wrote:
Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&...
There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away.
Perhaps these upstream CVS patches could be integrated into the Fedora Core patches. If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone.
John Thacker
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Emeric, list
I was wondering if there was a set of rpms anywhere for testing (I have a machine with ati / radeon hangs, Bug 175263, Bug 182196).
If not, I can see the patch (http://ucw.dustbite.net/xorg/xf86-video-ati-6.5.7.2-radeon_memmap_fix.patch....), and the SPRMS (http://download.fedora.redhat.com/pub/fedora/linux/core/test/4.92/source/SRP...)
Which rpms would need to be patched, I'm guessing at least xorg-x11-drv-ati but maybe whatever provides the kernel module, and mesa would need to be a different version? Any ideas or should I just wait?
-Cam
John Thacker wrote:
Mike A. Harris wrote:
Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&...
There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away.
Perhaps these upstream CVS patches could be integrated into the Fedora Core patches.
The great thing about modular X, is that it makes it possible for X.Org to release new versions of individual components much more easily. This means that problems of this nature which get fixed, can be integrated into the next stable bugfix release of the particular component.
Any patches that get committed to the CVS head of any given component in X.Org, show commitment that they'll be present in the next major release of the X Window System - 7.1. If the upstream developers feel confident about a particular patch being stable for the existing release, they can commit it to the stable branch of the particular component and release an update of that specific component, without having to release the entire window system.
Once upstream has integrated the patches into the stable branch, and has released an updated set of packages with the fixes present, we will consider releasing a Fedora Core 5 update to the new packages.
If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone.
My current plan for the r300 dri driver, is to leave it out of FC5, and once the various issues are resolved upstream we will re-enable it in rawhide post-FC5. This will allow the driver to get the level of testing that is needed, and hopefully to stabilize sooner. Then, once the major problems are resolved upstream by X.Org/DRI developers, and new upstream stable packages have been released with the fixes, we will probably include them in rawhide.
If the r300 DRI support matures upstream enough that it is not going to be a major support burden, then we will consider enabling it in a future FC5 update.
On Mon, Feb 27, 2006 at 07:11:34AM -0500, Mike A. Harris wrote:
My current plan for the r300 dri driver, is to leave it out of FC5, and once the various issues are resolved upstream we will re-enable it in rawhide post-FC5. This will allow the driver to get the level of testing that is needed, and hopefully to stabilize sooner. Then, once the major problems are resolved upstream by X.Org/DRI developers, and new upstream stable packages have been released with the fixes, we will probably include them in rawhide.
Sounds decent. I'd be extremely reluctant to update FC5 to something that's only in CVS. The only reason for suggesting it is that it seemed like you were saying that some people were seeing lockups even with the r300 dri driver from Mesa not even present on their system. Maybe I misread it, but if it turns out that there's no other way to prevent hangs on r300-based cards then the CVS patches should perhaps be considered.
Note that some of the bug reports claim that even without DRI lockups occur from using the framebuffer device, and that a lot of the patches apply to the main radeon X driver rather than dri. I don't know if removing the dri driver is enough to fix it. Hopefully so.
John Thacker
John Thacker wrote:
On Mon, Feb 27, 2006 at 07:11:34AM -0500, Mike A. Harris wrote:
My current plan for the r300 dri driver, is to leave it out of FC5, and once the various issues are resolved upstream we will re-enable it in rawhide post-FC5. This will allow the driver to get the level of testing that is needed, and hopefully to stabilize sooner. Then, once the major problems are resolved upstream by X.Org/DRI developers, and new upstream stable packages have been released with the fixes, we will probably include them in rawhide.
Sounds decent. I'd be extremely reluctant to update FC5 to something that's only in CVS. The only reason for suggesting it is that it seemed like you were saying that some people were seeing lockups even with the r300 dri driver from Mesa not even present on their system. Maybe I misread it, but if it turns out that there's no other way to prevent hangs on r300-based cards then the CVS patches should perhaps be considered.
There are multiple different problems, rather than a single problem.
Some users experience lockups or otherwise non-working X without the r300_dri driver present. That issue is still there, and hopefully can be diagnosed and fixed for FC5.
With the r300_dri driver installed, users who do not experience the above problem (or problems - there are many reports, and it may be multiple bugs), may still have hangs wether or not the "Load "dri"" is present or not, and wether or not "Option "nodri"" is specified.
If none of these problems happen, and no other non-3D related hang kills a person's system, then it is just a crapshoot wether DRI enabled operation will work on a given R300 or higher card with the driver present, and what magic incantations might be needed to get it to work on a given motherboard.
All and all, R300+ support is quite shaky right now, both 3D and 2D, so it is a process of reducing the instability by removing variables, and then over time resolving issues one at a time. The priority for FC5 is to get as many people's systems in "X starts and I can surf the web" state. Anything on top of that is icing on the cake, and bonus-plan material. If we can get to that state, there will be far fewer incoming bug reports when FC5 goes out the door, giving us much more time to spend fixing bugs rather than triaging mass bug duplicates.
Note that some of the bug reports claim that even without DRI lockups occur from using the framebuffer device, and that a lot of the patches apply to the main radeon X driver rather than dri. I don't know if removing the dri driver is enough to fix it. Hopefully so.
Exactly. There is no "it". There are numerous bugs occuring, some of which might even be kernel related. Removing the dri driver, removes incoming bug reports related to people who are trying to use the DRI driver, when it is known to be unstable and experimental by definition, allowing us to concentrate on bugs that are occuring with the non-experimental code.
Anyway, it's a done deal.
-
Camilo Mesias -
David Nielsen -
John Thacker -
Mike A. Harris -
Émeric Maschino