Re: [Dri-devel] Re: sched_yield()
On Llu, 2003-07-07 at 07:44, Linus Torvalds wrote: I'm pretty sure that the futex code is backported at least into the redhat tree, since the new threading code really really wants it. But yes, it may not be in any official 2.4.x kernels, and I suspect it's only in the most recent RH trees too. Futex and NPTL is in some of the Red Hat trees. Some of the stranger bits are not present. The backport itself is non trivial but patches do exist. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Ian Romanick wrote: Ian Romanick wrote: Linus Torvalds wrote: You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention. You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. I don't know if there's anyone working on DRI right now that knows enough about Linux and *BSD to be able to determine what the effort would be to make futex'es or a futex-like wrapper for those systems. I honestly believe that is the only reason we haven't already started using futex'es. We also have the problem of having to support old kernels with new user-mode drivers. Hmmm...I'll have to look in to futex'es more... As promised, I have finally looked into the mystical futex. The short version is that it should be dead simple to convert the existing DRI drivers to use either the existing locking method or a futex. And now for the rest of the story... A futex is actually very similar to the existing DRI lock. This is the main thing that will make transitioning the to futex interface so simple. Basically, a futex is just a variable in shared memory. When a thread wants to acquire the futex it decrements the variable. If it's non-negative, the thread happily continues on. If the value is negative, the thread calls into the kernel to block. At this point, the futex is virtually identical to the existing DRI lock. The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock. I don't think you can get the same behaviour as the DRI lock from just a futex alone. Specifically, the DRI lock makes it easy to notice when you weren't the last locking context, eg: Context A locks Context A unlocks Context A locks Here both Futex DRI lock say OK, nothing to do, context A gets the lock Context A unlocks Context B locks At this point, a native futex would say ok, B gets the lock, no problems, nothing to do, wheras the DRI lock would say Agh! different context grabbing the lock, gotta do some extra work, specifically set the hardware up the way B expects it to be. Now, in the original DRI design, it was concieved that the kernel would do a lot of that extra work to virtualize the hardware, while actually we end up doing it all in userspace. I guess all this means is that we need a 'last context' variable in addition to the futex, to detect this situation. But that does mean that we have to alter (slightly) the sarea layouts, right? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [TRIVIAL] Re: fix undefined reference for sis drm.
[ CONFIG_DRM_SIS needs CONFIG_FB_SIS to compile, of course. --RR ] (OK from maintainer Rik Faith [EMAIL PROTECTED]) From: Geoffrey Lee [EMAIL PROTECTED] Yep. Take one was pretty silly. Here's a better one. -- G. -- char p[] = xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd x80xe8xdcxffxffxff/bin/sh; --- trivial-2.4.22-pre3/drivers/char/drm/Config.in.orig 2003-07-07 15:33:24.0 +1000 +++ trivial-2.4.22-pre3/drivers/char/drm/Config.in 2003-07-07 15:33:24.0 +1000 @@ -13,4 +13,5 @@ dep_mbool'Enabled XFree 4.1 ioctl interface by default' CONFIG_DRM_I810_XFREE_41 $CONFIG_DRM_I810 dep_tristate ' Intel 830M' CONFIG_DRM_I830 $CONFIG_AGP dep_tristate ' Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP -dep_tristate ' SiS' CONFIG_DRM_SIS $CONFIG_AGP +dep_tristate ' SiS' CONFIG_DRM_SIS $CONFIG_AGP $CONFIG_FB_SIS + -- What is this? http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/ Don't blame me: the Monkey is driving File: Geoffrey Lee [EMAIL PROTECTED]: Re: [PATCH] fix undefined reference for sis drm. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the Reassign bug to owner of selected component option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the Accept bug command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=120 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=271 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=344 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [TRIVIAL] Re: fix undefined reference for sis drm.
On Llu, 2003-07-07 at 06:41, Rusty Trivial Russell wrote: [ CONFIG_DRM_SIS needs CONFIG_FB_SIS to compile, of course. --RR ] (OK from maintainer Rik Faith [EMAIL PROTECTED]) From: Geoffrey Lee [EMAIL PROTECTED] And the 2.4 config tools cant handle this because of the order problems. Marcelo please reject this again. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] sched_yield()
On Mon, 2003-07-07 at 08:12, Ian Romanick wrote: The one catch that I see is that I don't see support for the futex ioctl in any 2.4 kernel. I did a 'grep -ri futex include/' in the source for 2.4.21-ac2 and for 2.5.69. The 2.4 kernel didn't have any hits, but the 2.5 kernel did. Of course, this doesn't mean that support isn't there, it just means that it might be more challenging to build a driver on a box with only 2.4 kernel sources installed. The solution is to have our own copy of anything that isn't provided by all kernels we support. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
--- Additional Comments From [EMAIL PROTECTED] 2003-07-06 18:33 --- Hi Christopher, The problem isn't that 3D isn't supported by DRI, but rather that the Linux kernel does not yet support agpgart on Radeon IGP chipsets, and without working agpgart, you have no DRI. Theoretically it may be possible to use pcigart, by using ForcePCIMode, but I've no idea if there are other problems that would prevent that from working or not. Is this one of the many reasons why Radeon IGP 320/340M chips aren't yet supported too? Luis --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Problem with latest trunk and i810?
Ronald Baljeu wrote: On Mon, Jul 07, 2003 at 09:59:15AM +0100, Keith Whitwell wrote: Ronald Baljeu wrote: The traditional approach would be to do a binary search to narrow down which change caused the problems -- probably using the DRI cvs tree. Keith Ok, after several days of searching I think I found something here. In i810_dri.c of the Xfree CVS (I could not get into the DRI CVS) several calls are made to drmAgpAlloc(). To test whether this call was successful the returned handle is checked: if it is 0 it is assumed the call failed. Like this: drmAgpAlloc(pI810-drmSubFD, back_size, 0, NULL, agpHandle); if (agpHandle != 0) /* ok */ else /* error */ However I think 0 is a legal handle. Shouldn't the return value of the call be checked instead? Looking at the kernel modules and header files I noticed how this used to work this way. The agpHandle used to be a pointer internally (in the agp_memory struct), but it has been changed to a key. It's difficult to describe what I mean. Maybe this helps: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c: call to drmAgpAlloc() as described above xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c: body of drmAgpAlloc(), with a call to ioctl(DRM_IOCTL_AGP_ALLOC) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h: #define DRM_IOCTL_AGP_ALLOC DRM_IOWR(0x34, drm_agp_buffer_t) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h: mapping DRM_IOCTL_AGP_ALLOC to DRM(agp_alloc) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_agpsupport.h: body of DRM(agp_alloc) In the body of DRM(agp_alloc) a small change was made from: entry-handle= (unsigned long)memory-memory; to: entry-handle= (unsigned long)memory-key; So, tracing this back from kernel to userland, this key is now passed as agpHandle in the example above, instead of the memory pointer. Now the handle can legally be 0, but the source of i810_dri.c still treats it like a pointer of which 0 indicates an error. Could this be the source of the problem? Or am I way off ;-) Ronald, If you're way off, at this point it sounds like you've got a better idea than I... I'm forwarding this to dri-devel in the hope that this rings a bell with someone there. From CVS you can tell who made the change - that might help to get a quick response... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 44] Radeon Driver hard locks during VT switches/resolution changes 8500DV DRI only
[This e-mail has been automatically generated.] 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//cgi-bin/bugzilla/show_bug.cgi?id=44 --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 13:37 --- Thanks for the comments Roy. I agree with you: I think this is only occuring with certain combinations of mobo/chipsets and video cards. And, to tell you the truth, I wouldn't be surprised if it was Via's fault ;-). I hate that company more and more as I continue to painstakingly use their products. I did some scouring of the web and I found out that Mike Harris @ Redhat was actually working on this problem back when it was popping up for RH users while X was at 4.2. He wrote a patch for radeon_drv that claimed to FIX the problem, and that patch was integrated into the Redhat XFree86 4.2 rawhide. Unfortunately, the patch is no longer available on his site. I did see a bunch of other X patches there... ftp://people.redhat.com/mharris/ I personally have no clue how Redhat development works, but aren't patches like this sent back to the XFree team to be integrated into the source tree/CVS there? Or is this patch currently only available to Redhat users? In the errata that includes the patch, Redhat writes: Fix a problem which caused certain combinations of Radeon and Rage 128 hardware and particular motherboards to hang, due to bus mastering getting disabled when VT switching. Check out the bugzilla bug report here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62171 And the errata here: http://rhn.redhat.com/errata/RHSA-2003-066.html Maybe this sheds some more light on the issue? -Andrew --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] how to enable Mesa Verbose Debugging in the DRI-tree?
Am 2003.07.06 06:03:54 +0200 schrieb(en) Ian Romanick: Andreas Stenglein wrote: how to enable Mesa Verbose Debugging in the DRI-tree? http://mesa3d.org/debugging.html didnt help much It depends on the driver. Most of the drivers have an environment variable that's *_DEBUG (i.e., for the Radeon it's RADEON_DEBUG) that can be set to different values to generate debug output. You'll have to look in each driver (usually in the *_context.c file) to see what the possible values are. yes, I'm aware of those. But I want to enable the debugging of the mesa code, which is under xc/xc/extras/Mesa/src And that get enabled with MESA_VERBOSE / MESA_DEBUG if support for it is compiled in. Or doesnt that make sense at all for DRI ? I have a binary only demo that looks ok with sw-rendering, but shows errors on radeon, current DRI drivers; and on G400, XFree 4.2 drivers. greetings, Andreas --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 44] Radeon Driver hard locks during VT switches/resolution changes 8500DV DRI only
[This e-mail has been automatically generated.] 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//cgi-bin/bugzilla/show_bug.cgi?id=44 --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 17:45 --- The patch is no longer needed because the fix has been integrated. Still, I've been asking in this very bug about the status of bus mastering when it happens - have you checked it? The fact that it only happens when VT switching back to the server or when switching modes points towards starting the CP as causing the problems. Unfortunately, I don't have any idea what could go wrong there (and it seems to work perfectly on the vast majority of systems). I'm adding Hui Yu to the CC list, hoping he can think of something. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [TRIVIAL] Re: fix undefined reference for sis drm.
On Mon, 7 Jul 2003, Alan Cox wrote: On Llu, 2003-07-07 at 06:41, Rusty Trivial Russell wrote: [ CONFIG_DRM_SIS needs CONFIG_FB_SIS to compile, of course. --RR ] (OK from maintainer Rik Faith [EMAIL PROTECTED]) From: Geoffrey Lee [EMAIL PROTECTED] And the 2.4 config tools cant handle this because of the order problems. Marcelo please reject this again. Oops, I just had it applied. Reverting... Alan saves the day again. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Ian Romanick wrote: The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock. I wonder if we didn't throw out the baby with the bathwater when we reorganized the kernel side DMA buffer management. To be more specific, we do call the kernel unlock routine when there is lock contention, but it's not clear which compile time code paths are used by Linux in the supporting DRM code responsible for waking up the contending thread. Check out DRM(unlock) in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h This is precisely where Linux specific support for wake-up the next waiting thread should reside. I see calls to wake_up_interruptible(dev-lock.lock_queue), but they are ifdef'ed by __HAVE_KERNEL_CTX_SWITCH. I'm not certain which compile time paths we're using in this code these days...but somebody is waking up the clients that are waiting for the lock and this is precisely where it should be happening. When it does happen here, this behavior would appear to be almost identical to the behavior of the futex you describe. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Problem with latest trunk and i810?
He looks to have something here, alright.. the key can be zero, I'm just updating to trunk at the moment to see if I can reproduce it.. the radeon_dri.c has a similiar issue but it isn't as serious in their case, they check for freeing the AGP memory if (info-agpMemHandle) they use the return value to do do the setup... (this might explain some of the radeon mode switcihing issues??) so as far as I can see we've probably 3 choices, a)add isValid variables to the I810Rec strucutre for each handle, b) switch to signed long types for the handles and use -1 as an illegal handle (the keys are only signed ints) c) leave types as unsigned longs and use 0x as an illegal handle value... and of course d) revert back to using memory-memory, requires whoever switched us to key to explain :-) Dave. On Mon, 7 Jul 2003, Keith Whitwell wrote: Ronald Baljeu wrote: On Mon, Jul 07, 2003 at 09:59:15AM +0100, Keith Whitwell wrote: Ronald Baljeu wrote: The traditional approach would be to do a binary search to narrow down which change caused the problems -- probably using the DRI cvs tree. Keith Ok, after several days of searching I think I found something here. In i810_dri.c of the Xfree CVS (I could not get into the DRI CVS) several calls are made to drmAgpAlloc(). To test whether this call was successful the returned handle is checked: if it is 0 it is assumed the call failed. Like this: drmAgpAlloc(pI810-drmSubFD, back_size, 0, NULL, agpHandle); if (agpHandle != 0) /* ok */ else /* error */ However I think 0 is a legal handle. Shouldn't the return value of the call be checked instead? Looking at the kernel modules and header files I noticed how this used to work this way. The agpHandle used to be a pointer internally (in the agp_memory struct), but it has been changed to a key. It's difficult to describe what I mean. Maybe this helps: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c: call to drmAgpAlloc() as described above xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c: body of drmAgpAlloc(), with a call to ioctl(DRM_IOCTL_AGP_ALLOC) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h: #define DRM_IOCTL_AGP_ALLOC DRM_IOWR(0x34, drm_agp_buffer_t) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h: mapping DRM_IOCTL_AGP_ALLOC to DRM(agp_alloc) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_agpsupport.h: body of DRM(agp_alloc) In the body of DRM(agp_alloc) a small change was made from: entry-handle= (unsigned long)memory-memory; to: entry-handle= (unsigned long)memory-key; So, tracing this back from kernel to userland, this key is now passed as agpHandle in the example above, instead of the memory pointer. Now the handle can legally be 0, but the source of i810_dri.c still treats it like a pointer of which 0 indicates an error. Could this be the source of the problem? Or am I way off ;-) Ronald, If you're way off, at this point it sounds like you've got a better idea than I... I'm forwarding this to dri-devel in the hope that this rings a bell with someone there. From CVS you can tell who made the change - that might help to get a quick response... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Problem with latest trunk and i810?
and of course d) revert back to using memory-memory, requires whoever switched us to key to explain :-) Okay this was done by David Dawes back in April, and was taken from the XFree trunk, it looks like it is needed. so one of the other three approaches is needed... Dave. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
