intel DRI driver crash
With a clean Mesa build as of yesterday, glxgears is crashing at:
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
#1 0x2839dd6d in _mesa_resize_framebuffer (ctx=0x80af000, fb=0x8060400,
width=300, height=300) at main/framebuffer.c:331
#2 0x2834b612 in intelWindowMoved (intel=0x80af000) at
intel_context.c:576
#3 0x2834b6fa in intelMakeCurrent (driContextPriv=0x80521e0,
driDrawPriv=0x80eff00, driReadPriv=0x80eff00) at intel_context.c:612
#4 0x2832cee6 in DoBindContext (dpy=0x805e000, draw=54525954,
read=54525954,
ctx=0x80695b0, modes=0x8055500, psp=0x8069300)
at ../common/dri_util.c:343
#5 0x2832cf7e in driBindContext (dpy=0x805e000, scrn=0, draw=54525954,
read=54525954, ctx=0x80695b0) at ../common/dri_util.c:376
#6 0x280abe29 in BindContextWrapper () from /usr/X11R6/lib/libGL.so.1
#7 0x280ac2b7 in glXMakeCurrentReadSGI ()
from /usr/X11R6/lib/libGL.so.1
#8 0x280ac37e in glXMakeCurrent () from /usr/X11R6/lib/libGL.so.1
#9 0x0804b7d2 in ?? ()
...
(gdb) frame 0
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
384if (buffer-Name) {
(gdb) p buffer
$1 = (struct gl_framebuffer *) 0x0
Anyone else seeing this?
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel DRI driver crash
On Sun, 2006-06-18 at 20:38 -0700, Eric Anholt wrote:
With a clean Mesa build as of yesterday, glxgears is crashing at:
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
#1 0x2839dd6d in _mesa_resize_framebuffer (ctx=0x80af000, fb=0x8060400,
width=300, height=300) at main/framebuffer.c:331
#2 0x2834b612 in intelWindowMoved (intel=0x80af000) at
intel_context.c:576
#3 0x2834b6fa in intelMakeCurrent (driContextPriv=0x80521e0,
driDrawPriv=0x80eff00, driReadPriv=0x80eff00) at intel_context.c:612
#4 0x2832cee6 in DoBindContext (dpy=0x805e000, draw=54525954,
read=54525954,
ctx=0x80695b0, modes=0x8055500, psp=0x8069300)
at ../common/dri_util.c:343
#5 0x2832cf7e in driBindContext (dpy=0x805e000, scrn=0, draw=54525954,
read=54525954, ctx=0x80695b0) at ../common/dri_util.c:376
#6 0x280abe29 in BindContextWrapper () from /usr/X11R6/lib/libGL.so.1
#7 0x280ac2b7 in glXMakeCurrentReadSGI ()
from /usr/X11R6/lib/libGL.so.1
#8 0x280ac37e in glXMakeCurrent () from /usr/X11R6/lib/libGL.so.1
#9 0x0804b7d2 in ?? ()
...
(gdb) frame 0
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
384if (buffer-Name) {
(gdb) p buffer
$1 = (struct gl_framebuffer *) 0x0
Anyone else seeing this?
Update your CVS.
I've already fixed this.
Alan.
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7260] mach64 texture memory mng cleanup
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7260 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #5967 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-06-20 08:55 --- Created an attachment (id=5993) -- (https://bugs.freedesktop.org/attachment.cgi?id=5993action=view) use dri/common/texmem.c - try 2 This patch updates mach64UploadMultiTexImages() (for collocating two textures in the same heap) to always try the AGP heap. This is as far as I am willing to go and I think its at least as good as it was. So, I think this patch is ready for review. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6357] savage problem: glxgears produce black window
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6357 --- Additional Comments From [EMAIL PROTECTED] 2006-06-20 09:30 --- (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 [EMAIL PROTECTED], 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 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: Mike Mestnik wrote: How do I prove that? I'm thinking they might try and say that a software mesa path is calling this, I'd assume that internally you would call something like _glStencilFunc. My other problem is that if the error is caught, why is the screen all black? What would be the next step in tracking this down be? Figure out what value is being passed to glStencilFunc. Try applying the attached patch. That will print the value of the stencil function to the error message that you're already getting. I don't know why the patch file was empty. Let's try again... I got it from CVS. I have a problem with my new audio(spdif) setup that causes some other problems now. I'll get back to you if/when I can reproduce this error. What I hate the most is that I was playing this game until I upgraded trying to get doom3 working. At that time I was only using snapshots. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Mike Mestnik [EMAIL PROTECTED] wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this Re: Grand Theft Auto III, in game black screen. by ovek on Tuesday June 20, 2006 @ 4:07AMnew. That is normal. GTA3 initially sets an invalid stencil operation (zero), which Cedega converts into an invalid enum (zero) when converting it into a glStencilFunc call, and Mesa doesn't like it. Since stenciling is also disabled, this is not a problem. The game does set a valid stencil operation when it actually needs stenciling. The reason you don't see the message when you use LIBGL_ALWAYS_INDIRECT is because when doing indirect rendering, you no longer use Mesa client side. The server side Mesa, running inside the X server, can neither see your environment variables nor output to your terminal. is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: g400 vanilla 2.6.17 DRI
DRI with Matrox G400 was broken since 2.6.12, in result, we stuck at 2.6.11.12.But Matrox works correctly on current kernel with DRI from 7.0 or CVS.-- Free Software - find interesting programs and change themNetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame themDecopter - unrealistic helicopter simulator, get it from http://decopter.sf.net -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
