[Bug 9103] _ae_invalidate_state: Assertion `!actx-mapped_vbos' failed
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=9103 --- Additional Comments From [EMAIL PROTECTED] 2006-11-21 16:50 --- (In reply to comment #4) Roland, does doom run if you simply remove/disable the assertion? Unfortunately not. It will just trigger another assertion (_ae_unmap_vbos, line 1235), removing this one will cause a segfault (in mesa_buffer_map, line 364). If noone beats me to it, I'll look into it (tomorrow). -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9103] _ae_invalidate_state: Assertion `!actx-mapped_vbos' failed
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=9103 --- Additional Comments From [EMAIL PROTECTED] 2006-11-21 16:25 --- Roland, does doom run if you simply remove/disable the assertion? -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9103] _ae_invalidate_state: Assertion `!actx-mapped_vbos' failed
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=9103 --- Additional Comments From [EMAIL PROTECTED] 2006-11-21 16:22 --- Corresponding backtrace for that r200 doom3 crash (with tcl_mode 0, it segfaults with 1 too): #0 0x40017410 in ?? () #1 0xbfc8eed0 in ?? () #2 0x0006 in ?? () #3 0x7bd9 in ?? () #4 0x4024a7a1 in raise () from /lib/tls/libc.so.6 #5 0x4024bf79 in abort () from /lib/tls/libc.so.6 #6 0x40243fe3 in __assert_fail () from /lib/tls/libc.so.6 #7 0x4191ab13 in _ae_invalidate_state (ctx=Variable ctx is not available. ) at main/api_arrayelt.c:1301 #8 0x4198898d in _tnl_InvalidateState (ctx=Variable ctx is not available. ) at tnl/t_context.c:158 #9 0x418efcaf in r200InvalidateState (ctx=0xa9bfd90, new_state=1024) at r200_state.c:2633 #10 0x41960041 in _mesa_update_state_locked (ctx=Variable ctx is not available. ) at main/state.c:1107 #11 0x419600e8 in _mesa_update_state (ctx=0xa9bfd90) at main/state.c:1118 #12 0x419b4300 in _tnl_flush_vtx (ctx=0xa9bfd90) at tnl/t_vtx_exec.c:277 #13 0x419ac46a in _tnl_wrap_buffers (ctx=Variable ctx is not available. ) at tnl/t_vtx_api.c:84 #14 0x419ac527 in _tnl_wrap_filled_vertex (ctx=0x0) at tnl/t_vtx_api.c:121 #15 0x419b1a13 in attrib_0_3 (v=Variable v is not available. ) at tnl/t_vtx_generic.c:100 #16 0x419af471 in _tnl_Vertex3fv (v=0x10d4461c) at tnl/t_vtx_generic.c:240 #17 0x4191b19d in _ae_loopback_array_elt (elt=629) at main/api_arrayelt.c:1286 #18 0x41a4a237 in fallback_drawelements (ctx=Variable ctx is not available. ) at tnl/t_array_api.c:75 #19 0x08156450 in ?? () -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
Phillip Ezolt wrote: Roland, On 11/21/06, *Roland Scheidegger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Phillip Ezolt wrote: It does get recognized as PCI. However, I had to force it PCIE. (using OptionBusType PCIE). These cards are definately PCIE, so the original detection was wrong. I wonder if the MC_AGP_LOCATION register means something different on the 200M. These cards have an extra PCIE component which is supposed to shuffle graphics stuff to and from the memory. (This is in addition to the normal channels to and from the graphics card..) I'd be surprised if it's really different. I'd suspect that addresses within the AGP space just go untranslated to the bus without address translation as they did with other chips (with the chipset being responsible for translation). In any case, setting this up without RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx configures a 128MB window there. Maybe the chipset actually does some kind of agp gart remapping when set up correctly. Hmm. Maybe I just stumbled upon something good by accident. Like I said in the original email, there are still problems (garbage on the top half of the screen, and the hang). It's a bit weird. Maybe this is how the uma+sideport setting works. Should I read the value of RADEON_AGP_BASE when I have the working 8.24.8 driver and try to set that as well in the DRM module? You can't just change that in the drm I think. This PCI Express auxiliary memory channel is effectively a 64-bit memory channel with access to system memory. This means that a VPU equipped with a 64-bit local graphics memory bus and a PCI Express auxiliary memory channel has an effective 128-bit memory bus. So, it looks as if there is at least two channels out of the card when it has hypermemory. I think this is really only true for the xpress200 igps with local ram in interleaved mode. I've never seen anything indicating that the normal chips are actually able to split data like that - though careful placing of some buffers in system ram and some other buffers in local ram might indeed increase available bandwidth a bit slightly. But there isn't really any additional memory channel involved in this case, it's just the ability of the gpu's memory controller to read from system ram directly, which it has had since ages... (Gee, ATI, specs would be nice..) You don't have a xpress200 with local ram (sideport), right? I think something strange is going on with that agp location stuff. My laptop has 128M of sideport memory, and I have the BIOS configured so there is 128M of sideport + 128M of UMA memory. (for a total of 256M). Ah! Is that interleaved or not? This setup is likely more complicated to configure correctly than just using sideport (or uma) alone. I could be wrong though, with some luck the chip / bios handles this fully transparent on its own. Interestingly, the fgrlx v8.24.8 driver (the one that works...), only detects 128M of memory. The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly after start up), detects 256M of memory, and has a different value for the MC_AGP_LOCATION. So, I'm guessing, that the v8.24.8 driver is probably exclusively using either the UMA or Sideport memory (and working correctly..). I don't know which (and I don't know how to figure it out... ;-) ) This sounds like a very reasonable assumption. I think you should play around with the bios settings and see what happens. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
Roland, On 11/21/06, Roland Scheidegger [EMAIL PROTECTED] wrote: Phillip Ezolt wrote: It does get recognized as PCI. However, I had to force it PCIE. (using OptionBusType PCIE). These cards are definately PCIE, so the original detection was wrong. I wonder if the MC_AGP_LOCATION register means something different on the 200M. These cards have an extra PCIE component which is supposed to shuffle graphics stuff to and from the memory. (This is in addition to the normal channels to and from the graphics card..) I'd be surprised if it's really different. I'd suspect that addresses within the AGP space just go untranslated to the bus without address translation as they did with other chips (with the chipset being responsible for translation). In any case, setting this up without RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx configures a 128MB window there. Maybe the chipset actually does some kind of agp gart remapping when set up correctly. Hmm. Maybe I just stumbled upon something good by accident. Like I said in the original email, there are still problems (garbage on the top half of the screen, and the hang). Should I read the value of RADEON_AGP_BASE when I have the working 8.24.8driver and try to set that as well in the DRM module? The hypermemory whitepaper gives more details: http://ati.amd.com/technology/HyperMemory_Whitepaper.pdf. Several people have said that Hypermemory is just a fancy algorithm to move from graphics card memory to main memory. From my reading of that white paper, there is actually more to it.. they have an auxiliary memory channel. It's hard to tell exactly what it is or how to control it. The paper has a fair amount of marketing speak, but look at the diagram on page 7.. And especially when they talk about the auxiliary memory channel. I'm not quite convinced this auxiliary memory channel really exists. Might be just the ability to access memory directly due to the pcie address remapper it has. Ok. That's what these slides seem to say: http://www.hothardware.com/viewarticle.aspx?page=2articleid=647 However, the whitepaper says: This PCI Express auxiliary memory channel is effectively a 64-bit memory channel with access to system memory. This means that a VPU equipped with a 64-bit local graphics memory bus and a PCI Express auxiliary memory channel has an effective 128-bit memory bus. So, it looks as if there is at least two channels out of the card when it has hypermemory. (Gee, ATI, specs would be nice..) You don't have a xpress200 with local ram (sideport), right? I think something strange is going on with that agp location stuff. My laptop has 128M of sideport memory, and I have the BIOS configured so there is 128M of sideport + 128M of UMA memory. (for a total of 256M). Interestingly, the fgrlx v8.24.8 driver (the one that works...), only detects 128M of memory. The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly after start up), detects 256M of memory, and has a different value for the MC_AGP_LOCATION. So, I'm guessing, that the v8.24.8 driver is probably exclusively using either the UMA or Sideport memory (and working correctly..). I don't know which (and I don't know how to figure it out... ;-) ) (I don't have access to the log files for these right now, but if you're interested, I can send them later tonight. ) Anyway. My Xorg.0.log is attached. It is a little chatty because I have RADEON_DEBUG enabled. (NOTE: There's one problem I know about.. I don't have r300_dri.so in the right place. However, having this missing shouldn't hang the box.) It's probably a good idea to NOT have it there for now - it's completely optional, xorg itself won't touch it (except aiglx). Ok. Cool. I won't worry about it then. Roland --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC: 2.6 patch] drivers/char/drm/drm_mm.c: remove unused exports
This patch removes two unused exports.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.19-rc5-mm2/drivers/char/drm/drm_mm.c.old 2006-11-21
20:08:02.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/char/drm/drm_mm.c 2006-11-21
20:09:19.0 +0100
@@ -177,8 +177,6 @@
return 0;
}
-EXPORT_SYMBOL(drm_mm_init);
-
void drm_mm_takedown(drm_mm_t * mm)
{
struct list_head *bnode = mm-root_node.fl_entry.next;
@@ -197,5 +195,3 @@
drm_free(entry, sizeof(*entry), DRM_MEM_MM);
}
-
-EXPORT_SYMBOL(drm_mm_takedown);
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VBO broken by changes in mesa
Rune Petersen wrote: Keith Whitwell wrote: I've fixed some typo's in this code - with luck this should be solved now? sorry no... If you can't find in the next day, would you mind disabling it for 6.5.2 release? OK, I've made some progress on the i915 at least, can you retry over there? Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
On 11/21/06, Roland Scheidegger [EMAIL PROTECTED] wrote: Phillip Ezolt wrote: Roland, On 11/21/06, *Roland Scheidegger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Phillip Ezolt wrote: It does get recognized as PCI. However, I had to force it PCIE. (using OptionBusType PCIE). These cards are definately PCIE, so the original detection was wrong. I wonder if the MC_AGP_LOCATION register means something different on the 200M. These cards have an extra PCIE component which is supposed to shuffle graphics stuff to and from the memory. (This is in addition to the normal channels to and from the graphics card..) I'd be surprised if it's really different. I'd suspect that addresses within the AGP space just go untranslated to the bus without address translation as they did with other chips (with the chipset being responsible for translation). In any case, setting this up without RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx configures a 128MB window there. Maybe the chipset actually does some kind of agp gart remapping when set up correctly. Hmm. Maybe I just stumbled upon something good by accident. Like I said in the original email, there are still problems (garbage on the top half of the screen, and the hang). It's a bit weird. Maybe this is how the uma+sideport setting works. Should I read the value of RADEON_AGP_BASE when I have the working 8.24.8 driver and try to set that as well in the DRM module? You can't just change that in the drm I think. This PCI Express auxiliary memory channel is effectively a 64-bit memory channel with access to system memory. This means that a VPU equipped with a 64-bit local graphics memory bus and a PCI Express auxiliary memory channel has an effective 128-bit memory bus. So, it looks as if there is at least two channels out of the card when it has hypermemory. I think this is really only true for the xpress200 igps with local ram in interleaved mode. I've never seen anything indicating that the normal chips are actually able to split data like that - though careful placing of some buffers in system ram and some other buffers in local ram might indeed increase available bandwidth a bit slightly. But there isn't really any additional memory channel involved in this case, it's just the ability of the gpu's memory controller to read from system ram directly, which it has had since ages... (Gee, ATI, specs would be nice..) You don't have a xpress200 with local ram (sideport), right? I think something strange is going on with that agp location stuff. My laptop has 128M of sideport memory, and I have the BIOS configured so there is 128M of sideport + 128M of UMA memory. (for a total of 256M). Ah! Is that interleaved or not? This setup is likely more complicated to configure correctly than just using sideport (or uma) alone. I could be wrong though, with some luck the chip / bios handles this fully transparent on its own. Interestingly, the fgrlx v8.24.8 driver (the one that works...), only detects 128M of memory. The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly after start up), detects 256M of memory, and has a different value for the MC_AGP_LOCATION. So, I'm guessing, that the v8.24.8 driver is probably exclusively using either the UMA or Sideport memory (and working correctly..). I don't know which (and I don't know how to figure it out... ;-) ) This sounds like a very reasonable assumption. I think you should play around with the bios settings and see what happens. FWIW, I've heard reports of some XPRESS users having success with fglrx only after messing with the bios. Alex Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] mesa fbcon/dri
I'm just cc'ing your message to the DRI list so someone more involved in the DRI/kernel code can take a look at this. -Brian Robert Carter wrote: I saw the post from Lukas S about hardware GL without X11. My problem is similar but using a different method to solve, so i'll begin a new thread. I've read the document about fbdev/dri here: http://www.mesa3d.org/fbdev-dri.html I'm following the instructions to build kernel modules. I am designing for an embedded system, so the kernel is not the same as the currently running kernel. I use make like this to specify the kernel tree: [EMAIL PROTECTED]:~/drm/drm/linux# make LINUXDIR=~/kernel/linux-2.6.18/ make -C /home/rob/kernel/linux-2.6.18/ SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[1]: Entering directory `/home/rob/kernel/linux-2.6.18' CC [M] /home/rob/drm/drm/linux/i810_drv.o In file included from /home/rob/drm/drm/linux/drm_core.h:27, from /home/rob/drm/drm/linux/i810_drv.c:40: /home/rob/drm/drm/linux/drm_agpsupport.h:45: error: syntax error before ‘*’ token /home/rob/drm/drm/linux/drm_agpsupport.h:45: warning: type defaults to ‘int’ in declaration of ‘drm_agp’ ... It looks like i'm missing some headers or an environment path is missing. Do I need a kernel headers tarball in addition to the headers already included in the source tree? Thanks for any help Rob - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: Xserver crash and restart fails
Tino Keitel wrote: On Fri, Nov 17, 2006 at 22:12:09 +0100, Tino Keitel wrote: Hi folks, I use the TV application MythTV that uses OpenGL to draw its GUI. Since a while I can crash my Xserver very easy just by switching to the workspace that shows the MythTV GUI. A restart of the Xserver fails. I If this helps: I can stop the display manager, suspend to disk using suspend2, resume, and restart X. It seems to work again after this. Which version of the i915 driver are you using? Is it i915tex? If not, please upgrade to i915tex and retry. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
