[Dri-devel] [Bug 757] Cut and paste error in radeon_probe.c
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=757 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 04:36 --- Thanks for pointing this out. Fixed and scheduled for commit. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CVS merge problem solved + suggestion for cvs policy
Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag keyword-revision-fork cvs tag -b keyword-revision-branch Then a merge from trunk would be done with: cvs -update -d -j keyword-revision-fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Best regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: Log message: Add Merged Framebuffer (MergedFB) support to the radeon driver. On dualhead cards this creates a single shared framebuffer with 2 viewports looking into it. This allows things like the DRI to work on both heads. This also adds support for pseudo-xinerama so that xinerama aware apps will behave as expected in a dualheaded setup when used with MergedFB. Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.h radeon.man radeon_cursor.c radeon_driver.c radeon_video.c Revision ChangesPath 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 1.15 +126 -75 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c 1.65 +1505 -202 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.18 +174 -44 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snapshot script changes for xdriinfo
Felix, On Sat, Oct 04, 2003 at 01:35:13AM +0200, Felix Kühling wrote: Hi, I made some modifications to the snapshot scripts in order to include xdriinfo and its manpage in the snapshots of the config-0-0-1-branch or the trunk after the merge. A patch is attached. I chose to use the extras subdirectory with its own install script. The disadvantage is that this does not allow restoring of backup files on deinstallation. But this is no problem as these files don't exist XFree86 releases. The advantage is that I didn't have to touch the install script. I tested the modifications by building snapshots for the trunk and the branch with the changed scripts. They looked all right, though I didn't try a full installation. I only tested the generated extras.sh script. The last couple of snapshots were made with your changes applied and appear to be fine. Thanks for this patch - I'm sure it will be useful in several ocasions in the future. Jose Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag keyword-revision-fork cvs tag -b keyword-revision-branch Then a merge from trunk would be done with: cvs -update -d -j keyword-revision-fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. Jose Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
José Fonseca wrote: On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag keyword-revision-fork cvs tag -b keyword-revision-branch Then a merge from trunk would be done with: cvs -update -d -j keyword-revision-fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, 07 Oct 2003 12:32:45 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: José Fonseca wrote: On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag keyword-revision-fork cvs tag -b keyword-revision-branch Then a merge from trunk would be done with: cvs -update -d -j keyword-revision-fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? There may be more cases where you commit new revisions to imported sources. The result is the same except the number of files affected is probably smaller. OTOH I might report this as a bug against CVS and they should fix it :) Keith Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? I'd agree with Keith the proper way to merge needs documenting, CVS vendor import is what is needed, the XFree CVS is vendor imported into our DRI tree, the changes from the last XFree merge are then merged onto the trunk for files that we have changed... I recently (with some help) manually cleaned up some Linux-VAX development CVS trees that had been hand merged not using vendor stuff, it just takes judicious use of the cvs admin -b command... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
I would suggest adding more ioctls: 1. Lock the drm driver against future connections from 3d driver(s). 2. Return the number of current connections. 3. Move the aperture - should only succeed when nothing else is connected. Also, when aperture is moved DRM driver can simply refuse connection to older 3d drivers. Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. Our idea would be an ioctl to set the aperture position on startup and (possibly another one) for 3D clients to let the DRM know what they think the aperture position is. Then the DRM could fix up client commands as necessary. This would work with any 3D driver (except probably old incompatible ones from GATOS :). Well, fixing up commands might not be so trivial. With 4.3.0 drivers it turned out it was a lot easier to fix the 3d client. Of course, I am not an expert.. best Vladimir Dergachev -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MergedFB committed
Sorry, I forgot to post a patch of what went in. I committed this patch: http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Yeah. I'll work on that this week unless anyone has any objections. Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: Log message: Add Merged Framebuffer (MergedFB) support to the radeon driver. On dualhead cards this creates a single shared framebuffer with 2 viewports looking into it. This allows things like the DRI to work on both heads. This also adds support for pseudo-xinerama so that xinerama aware apps will behave as expected in a dualheaded setup when used with MergedFB. Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.h radeon.man radeon_cursor.c radeon_driver.c radeon_video.c Revision ChangesPath 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 1.15 +126 -75 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c 1.65 +1505 -202 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.18 +174 -44 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote: Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? I think tagging the branch point is a good idea regardless. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
Michel Dnzer wrote: On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote: Hmm. These problems only arise because of the way the merge was done? Why not just document the right way to do the merge? I think tagging the branch point is a good idea regardless. I agree. Documenting both the right way to do a merge *and* suggesting the extra tag (as a back-up) are good ideas. It would probably be a good idea to also document *why* these steps are desireable. :) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: Log message: Add Merged Framebuffer (MergedFB) support to the radeon driver. On dualhead cards this creates a single shared framebuffer with 2 viewports looking into it. This allows things like the DRI to work on both heads. This also adds support for pseudo-xinerama so that xinerama aware apps will behave as expected in a dualheaded setup when used with MergedFB. Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.h radeon.man radeon_cursor.c radeon_driver.c radeon_video.c Revision ChangesPath 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 1.15 +126 -75 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c 1.65 +1505 -202 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.18 +174 -44 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-10-07 at 10:42, Alex Deucher wrote: I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex Accepted practice, as far as I can tell, is that when you take code from one driver and adapt it into new files in another driver, you get to put your copyright on it. I've done this in the sis code, and VIA/S3 did it in the Savage code which still has a lot of Matrox code #ifdeffed out (or not, and just unused) in it. For the XFree86 CVS ID in a new file, just put: /* $XFree86$ */ and it'll get expanded by CVS when it's committed to the XFree86 repo. Or, you can leave it out and I think the XFree86 folks take care of adding it when it goes into their repo. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:15 --- I've tried: - XFree 4.3.99.11 and 4.3.99.13 with the patch #502 - linux 2.6.0-test4 and 2.6.0-test6 with the patch #540 (with somme change for 2.6.0-test6) - with and without the two environement variables in /etc/profile XFree is installed in /usr/local/X11, seems to work well without the kernel patch (software OpenGL) with both version. linux have a patch to change dsdt (acpi), and I've troubles with irq 10. When I use XFree with dri, logs say that I've dri, glxinfo too. But, when I use a 3D apps (glxgear and foobillard), XFree freeze. I can kill it with the magic key, and reboot with the power button (acpid), but It's take a long time, so I think that a prossessus use all the resources. I don't think that it's have any link with my problem with irq10 because this trouble freeze totaly the computer. If you need more info, ask. Thanks for your job. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] bug in light locks?
I've been trying to track down a DRI client and server deadlock problem. I think I now know the problem, I'd appreciate it if others could confirm this is a bug or if I have a misunderstanding. This is the scenario: 1) Client takes heavyweight lock via ioctl, lock now has DRM_LOCK_HELD bit or'ed in, high nibble is now 0x8. 2) Server requests heavyweight lock on a different context via ioctl, lock is held by client, server is suspened pending release of lock by client. The DRM_LOCK_CONT flag is or'ed in, high nibble is now 0xC. 3) Client wants to take lightweight lock, client currently holds lock. A CAS test is performed between the lock and (DRM_LOCK_HELD | context). The CAS test fails because even though the context is the same the high nibble now has both the DRM_LOCK_HELD and the DRM_LOCK_CONT flags or'ed into it. The test would have succeeded if the DRM_LOCK_CONT flags was not set. Because the test fails the client does not believe it owns the lock (but it does!) and then issues heavyweight ioctl lock on the very context it already owns the lock on. 4) In the kernel driver DRM(take_lock) discovers the lock is already held on that context by that process. It issues an ERROR message, and returns 0. A zero return value indicates the lock cannot be taken, it then suspends the client waiting for the lock to be released, but it is this client that holds the lock, both the client and server are now suspended both waiting for a lock release that will never occur, a classic deadlock. Assuming my analysis is correct I see the following possible solutions: 1) Invoke CAS twice, once with (DRM_LOCK_HELD | context) and if it fails try once again with (DRM_LOCK_HELD | DRM_LOCK_CONT | context) 2) remove the DRM_LOCK_CONT from the lock and put the flag elsewhere. 3) Have CAS (or better a macro that wraps it) mask out bits not belonging to the test (at the moment thats just DRM_LOCK_CONT). 4) Have DRM(take_lock) return TRUE if the lock is already held. I think this is a bad choice because it violates the locking semantics of no nested heavyweight locks in the driver. The client would continue to be confused over when to lock and unlock, thus no matter what the client needs to be fixed. Questions: 1) Does the analysis sound correct? 2) If so, which approach is preferred? I need to make a patch to fix this, might as well do in a manner that keeps the upstream developers happy. My personal preference is solution #3. John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:13 --- I've tried: - XFree 4.3.99.11 and 4.3.99.13 with the patch #502 - linux 2.6.0-test4 and 2.6.0-test6 with the patch #540 (with somme change for 2.6.0-test6) - with and without the two environement variables in /etc/profile XFree is installed in /usr/local/X11, seems to work well without the kernel patch (software OpenGL) with both version. linux have a patch to change dsdt (acpi), and I've troubles with irq 10. When I use XFree with dri, logs say that I've dri, glxinfo too. But, when I use a 3D apps (glxgear and foobillard), XFree freeze. I can kill it with the magic key, and reboot with the power button (acpid), but It's take a long time, so I think that a prossessus use all the resources. I don't think that it's have any link with my problem with irq10 because this trouble freeze totaly the computer. If you need more info, ask. Thanks for your job. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 110] Radeon DRI crashes.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=110 --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:51 --- I am having what looks to be the same problem. I have an ATI Radeon 7000 AGP, and certain 3d applications, but not all, seriously crash the machine. For example: UT2003 crashes immediately when 3d content is placed on the screen. One frame is displayed, and the machine completely locks up: does not respond to keystrokes, and I can not log in via ssh. I am running XFree86 4.3 under Linux kernel 2.4.22 (still trying to get the 2.6.0 test kernel to run), with the drm modules provided in the Xfree86 distribution. I have an AMD Athlon processor on a VIA kt400. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 110] Radeon DRI crashes.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=110 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] bug in light locks?
John Dennis wrote: I've been trying to track down a DRI client and server deadlock problem. I think I now know the problem, I'd appreciate it if others could confirm this is a bug or if I have a misunderstanding. This is the scenario: 1) Client takes heavyweight lock via ioctl, lock now has DRM_LOCK_HELD bit or'ed in, high nibble is now 0x8. 2) Server requests heavyweight lock on a different context via ioctl, lock is held by client, server is suspened pending release of lock by client. The DRM_LOCK_CONT flag is or'ed in, high nibble is now 0xC. 3) Client wants to take lightweight lock, client currently holds lock. These locks don't support recursive locking -- if this situation arises, the client is broken. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS merge problem solved + suggestion for cvs policy
On Tue, Oct 07, 2003 at 12:23:16PM +0100, José Fonseca wrote: On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote: Hi all, I'm happy to report that I found a solution to the merge problems Eric and I were seeing. I believe the problem had to do with vendor branches. They are created automatically when sources are imported using cvs import. Many files from XFree86 had a vendor branch (e.g. revisions 1.1.1.x) with several revisions, each corresponding to a cvs import. The config-0-0-1-branch and savage_1-0-0_branch were forked off such vendor branches of these files. However, the last merge from XFree86 was done using cvs commit instead of cvs import. Therefore the new head revision of the XFree86 files was e.g. 1.2. Now a normal cvs update -d -j HEAD would determine 1.1 as common ancestor revision of the branch and the current trunk while the real ancestor revision is 1.1.1.x (on a vendor branch). The solution is to explicitly specify the ancestor revision as the branch point. This is the command line I used for that purpose: cvs -z3 update -d -j config-0-0-1-branch:2003-05-25 -j HEAD where 2003-05-25 is the day before the first commit on the config-0-0-1-branch. Note that -kk is not necessary. In fact it produces unnecessary conflicts instead of preventing them. I suggest an update of the cvs policy in order to avoid such problems in the future. The above operation would have been easier with a tag marking the branch point. Thus creating a branch should consist of two steps: cvs tag keyword-revision-fork cvs tag -b keyword-revision-branch Then a merge from trunk would be done with: cvs -update -d -j keyword-revision-fork -j HEAD If I get positive feedback on this I would update the wiki page myself. Or simply if you don't get any negative feedback - maybe its the lack of some caffeine intake but I'm having troubles to grasp the CVS concepts you mentio, so I'll trust on your judgment, especially since it appears to simply the procedure considerably. This is a little puzzling to me to, as I did do the last merge with cvs import. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote: I would suggest adding more ioctls: 1. Lock the drm driver against future connections from 3d driver(s). 2. Return the number of current connections. 3. Move the aperture - should only succeed when nothing else is connected. Also, when aperture is moved DRM driver can simply refuse connection to older 3d drivers. Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. Why? (CC'ing Hui Yu, who should be able to comment on this) Would resetting the aperture to the default position on server shutdown deal with this adequately? Our idea would be an ioctl to set the aperture position on startup and (possibly another one) for 3D clients to let the DRM know what they think the aperture position is. Then the DRM could fix up client commands as necessary. This would work with any 3D driver (except probably old incompatible ones from GATOS :). Well, fixing up commands might not be so trivial. With 4.3.0 drivers it turned out it was a lot easier to fix the 3d client. The 3D drivers will be fixed at any rate. The idea is to preserve as much backwards compatibility with old 3D drivers as possible, at least to prevent them from taking down the machine or similar catastrophic failure. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] firstLevel / lastLevel calculation in R200 driver
Brian Paul wrote: Ian Romanick wrote: A long time ago I promided to refactor the firstLevel / lastLevel calculation code from the various *SetTexImages routines. I have a patch that does this, and it follows the definition of how firstLevel lastLevel selection should work pretty closely. The only problem is that this does NOT grok with the way the R200 driver calculates it for GL_TEXTURE_3D. 3D textures are supposed to work just like 1D, 2D, and cubemap textures. However, the R200 driver picks baseLevel for firstLevel and lastLevel. Does this represent some limitation of the r200 hardware or was it just an oversight? I know that 3D textures are not currently hardware accelerated, but they will be someday. I don't want to put code in that will break when that happens. Actually, I added support for HW 3D textures (and cube maps) last winter (or so). The r200 doesn't support mipmapped 3D textures, so that would have to be a fallback path, but non-mipmapped 3D textures are hardware accelerated. Okay. That explains it then. :) I modified enable_3d_tex to return FALSE (and cause a fallback) if the minfilter is not GL_NEAREST or GL_LINEAR. At some point we may want to add a config option to do per-polygon mipmapping (i.e., select a single level to use for the whole polygon) if one of the mipmap filter modes is selected. The one bit missing was support for glTexCoord3 in the vertex buffers. That's Keith's area of expertise. 3D texgen works though. I assume that's why ENABLE_HW_3D_TEXTURE is not set? Any idea what it would take to get that implemented? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote: I would suggest adding more ioctls: 1. Lock the drm driver against future connections from 3d driver(s). 2. Return the number of current connections. 3. Move the aperture - should only succeed when nothing else is connected. Also, when aperture is moved DRM driver can simply refuse connection to older 3d drivers. Does the aperture ever (have to) move during the X server life though? I would not care. However, I know that at least Window 98 drivers have default position (0) unless capture is enabled. Also, I suspect that when one calls Video BIOS with framebuffer position anywhere other than 0 the BIOS then toggles the hard reset line. Why? (CC'ing Hui Yu, who should be able to comment on this) No idea why it does it. Would resetting the aperture to the default position on server shutdown deal with this adequately? One would also need to do it each time before video bios is called, or prevent it from being called when we are in the middle of things. best Vladimir Dergachev --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
