[Dri-devel] G450 & X4.1.0m problems
Hi! Now I have tried everything to get DRI to work. Nothing has helped so far, though... Glxgears from X.4.1.0 still crasches the machine... According to the X-log and glxinfo everything seems OK... Can anyone see what might be wrong?? - strace /usr/X11/bin/glxgears : execve("/usr/X11/bin/glxgears", ["glxgears"], [/* 24 vars */]) = 0 brk(0) = 0x804beb8 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=32600, ...}) = 0 old_mmap(NULL, 32600, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3)= 0 open("/usr/lib/libGL.so.1", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=516790, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\340"..., 4096) = 4096 old_mmap(NULL, 432028, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000 mprotect(0x4008, 26524, PROT_NONE) = 0 old_mmap(0x4008, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x62000) = 0x4008 old_mmap(0x40084000, 10140, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40084000 close(3)= 0 open("/usr/X11R6/lib/libXext.so.6", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=64049, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200)\0"..., 4096) = 4096 old_mmap(NULL, 54908, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40087000 mprotect(0x40093000, 5756, PROT_NONE) = 0 old_mmap(0x40093000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x40093000 close(3)= 0 open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=1042711, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0E\1\000"..., 4096) = 4096 old_mmap(NULL, 914268, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40095000 mprotect(0x4017, 17244, PROT_NONE) = 0 old_mmap(0x4017, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xda000) = 0x4017 old_mmap(0x40174000, 860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40174000 close(3)= 0 open("/lib/libpthread.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=289906, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p?\0\000"..., 4096) = 4096 old_mmap(NULL, 74040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40175000 mprotect(0x4018, 28984, PROT_NONE) = 0 old_mmap(0x4018, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xa000) = 0x4018 old_mmap(0x40187000, 312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40187000 close(3)= 0 open("/lib/libm.so.6", O_RDONLY)= 3 fstat(3, {st_mode=S_IFREG|0755, st_size=527442, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320F\0"..., 4096) = 4096 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40188000 old_mmap(NULL, 117208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40189000 mprotect(0x401a5000, 2520, PROT_NONE) = 0 old_mmap(0x401a5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1b000) = 0x401a5000 close(3)= 0 open("/lib/libc.so.6", O_RDONLY)= 3 fstat(3, {st_mode=S_IFREG|0755, st_size=4101324, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096 old_mmap(NULL, 1001564, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401a6000 mprotect(0x40293000, 30812, PROT_NONE) = 0 old_mmap(0x40293000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xec000) = 0x40293000 old_mmap(0x40297000, 14428, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40297000 close(3)= 0 open("/lib/libdl.so.2", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=75131, ...}) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\34"..., 4096) = 4096 old_mmap(NULL, 12428, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4029b000 mprotect(0x4029d000, 4236, PROT_NONE) = 0 old_mmap(0x4029d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x4029d000 close(3)= 0 mprotect(0x401a6000, 970752, PROT_READ|PROT_WRITE) = 0 mprotect(0x401a6000, 970752, PROT_READ|PROT_EXEC) = 0 mprotect(0x4001d000, 405504, PROT_READ|PROT_WRITE) = 0 mprotect(0x4001d000, 405504, PROT_READ|PROT_EXEC) = 0 munmap(0x40015000, 32600) = 0 personality(PER_LINUX) = 0 getpid()= 14207 getpid()= 14207 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0 uname(
Re: [Dri-devel] Re: CVS Update: xc (branch: mesa-3-5-branch)
I can verify the unreal engine issues, though I have not had the time to test mesa-3-5-branch, if needed I can also try to help pin down what unreal is doing which nothing else does. (I'm seeing it in both the Rune and DeusEx ports, other problems with the ports have kept me busy debugging things so I have not poked at it too much from that side.) Zephaniah E. Hull. On Sun, Jun 24, 2001 at 11:45:32PM +0200, Dieter N?tzel wrote: > Hello Brian, hello Alan, > > now after that the mesa-3-5-branch is updated with the trunk we "only" need > Alan's fixes for the 4.1.0 tdfx driver plus the fixing of the remaining tdfx > (Voodoo5) UT texture bugs (picture is available). > > * context switching fix (the Khoros Pro 2001 thing) > > * (texture) memory calculation/reservation fix (the KDE KPager texture > corruption problem) > > * Xv bilinear filtering doesn't work above 1024x768x24 > > UT crash with the latest mesa-3-5-branch after some seconds. > It starts OK but you can look through all walls and objects. After some > seconds the whole X server hang and I have to reset or reboot. Most of the > time the magic keys do not work. Luckily I have ReiserFS running fine...:-) > > Regards, > Dieter > > BTW Excuse me if you get this twice. I had my mail configuration wrong. > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/dri-devel > -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Why blow away at a partition when you can chip away at it? I now present a script I just wrote that writes random bits of, well random bits, into random places in your favorite partition or file. For best (meaning most spectacular) results, use while the database or filesystem is in active use. Disclaimer: This code is untested, and it may or may not trash your filesystem and/or database. While at least a half-assed effort has been made to ensure that it works as designed, there is no guarantee that its use will result in a loss of important data. I am not liable for the lack of either direct or incidental damages. -- Logan Shaw on ASR. PGP signature
Re: [Dri-devel] What is the current state of acceleration support for Ati Mobility M4 (and other questions)?
The r128 support worked fine for us (after the usual install miseries) on an Inspiron with a Rage Mobility M3 AGP2x which we acquired about 10 months ago.. don't know about the M4 though. Mike 1) OK, I am still confused. Can someone please tell me is the DRI support working for the above-mentioned video card or not? ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: mesa-3-5-branch)
Hello Brian, hello Alan, now after that the mesa-3-5-branch is updated with the trunk we "only" need Alan's fixes for the 4.1.0 tdfx driver plus the fixing of the remaining tdfx (Voodoo5) UT texture bugs (picture is available). * context switching fix (the Khoros Pro 2001 thing) * (texture) memory calculation/reservation fix (the KDE KPager texture corruption problem) * Xv bilinear filtering doesn't work above 1024x768x24 UT crash with the latest mesa-3-5-branch after some seconds. It starts OK but you can look through all walls and objects. After some seconds the whole X server hang and I have to reset or reboot. Most of the time the magic keys do not work. Luckily I have ReiserFS running fine...:-) Regards, Dieter BTW Excuse me if you get this twice. I had my mail configuration wrong. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] What is the current state of acceleration support for Ati Mobility M4 (and other questions)?
Hello fellow Linux users! I am a long time linux user (well "long" here is a relative term, I guess, but I have been using linux since RH 5.2, so I guess that qualifies me as a non-newbie at least :-), but I only recently got involved in 3d design and programming (using primarily blender and Gtk+). Before, I used Linux primarily for sound processing. Anyhow, recently I invested into a laptop (dell inspiron 8000 1Ghz with Mobility m4), and after successfully installing Linux and getting X up I got somewhat dissapointed when I found out that there was no accelerated support for this video card that has been out for over 1/2 of year (needless to mention that it is probably most widely used in laptops -- although this might soon change due to debut of geforce2go cards). I researched a bit around and found out that AcceleratedX has support for it (costs $129 though, and does not tolerate presence of Mesa which is required for a lot of devel tools), as well as heard a rumour of DRI supporting acceleration. After a bit more of research I stumbled accross a lot of conflicting testimonies regarding DRI support (for instance on the DRI www site it mentions mobility being supported, but it does not specify which of the mobility family it supports). So this source of confusion is the primary reason why I am writing to ya all. I would greatly appreciate any help I can get in order to find answer(s) to below-included questions: 1) OK, I am still confused. Can someone please tell me is the DRI support working for the above-mentioned video card or not? 2) If it does, and I do have X running (stable and all that), what do I need to do to get DRI compiled, since my attempt sometime ago failed miserably due to some errors I was not able to circumvent (i.e. what Xfree version do I need, and what other stuff do I need on top of that? btw I am running RH7.0 with most of the latest updates, including Ximian Gnome 1.4)? 3) How does DRI acceleration compare to AcceleratedX and/or to Windoze performance (i.e. how would Quake3 perform on the same machine using Linux/X/DRI and using Windoze)? Any help would be utmostly appreciated! Sincerely, Ivica "Ico" Bukvic, composer ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel