Re: DRM_CAS bug with x86_64
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernardo Innocenti wrote: GAS choked on the DRM_CAS invocation in ffb_lock.h because __ret was declared as int and so it gets passed in %edx instead of %dl or %dh as required by the setnz instruction. I just wrapped the declaration with DRM_CAS_RESULT() as done elsewhere. This seems to have never hit us because on x86 the FFB driver no-ops its LOCK_HARDWARE and UNLOCK_HARDWARE macros. Can somebody please explain why that is? My *guess* is that FFB hardware can only actually exist on SPARC. I was wondering why ffb was even being built on x86_64. If it's referring to the board from Sun (which marketing called a Creator or Creator 3D), it was only ever made for the UPA bus (UltraSPARC Port Architecture), not PCI or any other common bus, and I've never seen a UPA bus outside of a SPARC machine. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
On 8/9/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi Michal, (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2bfc000 Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) bt No stack. This is very interesting - the program is killed rather than receive sig11 right after allocating SAREA. Which Linux kernel are you running ? Do you have anything like SELINUX or or out-of-memory handler enabled ? Anyone else has seen something like this before ? A friend got something similar (IIRC in fact X wouldn't start even without drm) with kernel patched for security, maybe gentoo one got things like that (selinux or whatever else). Trying an official kernel should help to see if this related. In the list of applied patch to your kernel there is a patch for security but not much is say on what it does (i am not in shape to take a look at what this patch is really :)) Jerome Glisse --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Hi, On Wednesday 10 of August 2005 10:28, you wrote: On 8/9/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi Michal, (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2bfc000 Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) bt No stack. This is very interesting - the program is killed rather than receive sig11 right after allocating SAREA. Which Linux kernel are you running ? Do you have anything like SELINUX or or out-of-memory handler enabled ? Anyone else has seen something like this before ? A friend got something similar (IIRC in fact X wouldn't start even without drm) with kernel patched for security, maybe gentoo one got things like that (selinux or whatever else). Trying an official kernel should help to see if this related. In the list of applied patch to your kernel there is a patch for security but not much is say on what it does (i am not in shape to take a look at what this patch is really :)) Thanks for information, Unfortunately yesterday I built vanilla kernel 2.6.12.4 and 2.6.13-rc6 from kernel.org - I got same results as with gentoo patched kernel. On Tuesday 09 of August 2005 19:10, Vladimir Dergachev wrote: On Tue, 9 Aug 2005, [iso-8859-2] Micha³ Pytasz wrote: Hi, On Tuesday 09 of August 2005 18:04, Vladimir Dergachev wrote: Version of my kernel is gentoo-2.6.12-r7, which is based on 2.6.12.3 (exact list of applied patches is here: http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/ ) I am attaching my kernel configuration. I could build vanilla kernel if it would help debug problem. Well, I ran out of ideas. If it is not too much trouble try a vanilla kernel, on the off chance that something is different there. Just tested it with vanilla kernel 2.6.13-rc6 - results are the same. What about 2.6.12-4 - there were some amd64 specific changes, though I am not certain whether they would apply here. For comparison here is the relevant part from my Xserver log: (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf99de000 (II) RADEON(0): [drm] mapped SAREA 0xf99de000 to 0xaf87a000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x3340; Card 0x1002/0x4e50] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 As you can see SAREA address is high too (this is on Pentium M, 32 bits) and the very next messages says that it was mapped at some virtual address in Xserver space. The code that does this is located in xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c If you feel like it poke around, insert some xf86DrvMsg(X_INFO, 0, hello) to see what happens. In particular it would be useful for another pair of eyes to check for the following: * any confusion between int, long and similar unsigned types * above, especialy as applied to addresses and sizes * does mmap work ok on your system ? Maybe some issues with flags passed to it ? Indeed an interesitng part is a very high address for SAREA, maybe it's some x86_64 specific issue? Look at length of displayed variable (x86_64 ponters are 8 bytes long): (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf99de000 in the log posted by Vladimir in comparison to my: (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2bfc000 On the other hand there are some warnings (about depricated functions, some of which are memory related): /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c: In function `compat_radeon_cp_init': /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74: warning: `is_pci' is deprecated (declared at /home/dduck/Download/DRI/drm/linux-core/radeon_drm.h:495) /home/dduck/Download/DRI/drm/linux-core/radeon_ioc32.c:74:
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
On 8/10/05, Michał Pytasz [EMAIL PROTECTED] wrote: Hi, Thanks for information, Unfortunately yesterday I built vanilla kernel 2.6.12.4 and 2.6.13-rc6 from kernel.org - I got same results as with gentoo patched kernel. I suggest testing a 2.6.12 not a 2.6.13, i think something might be wrong with 2.6.13 (IIRC i see people complaining on lkml or on dri user) a change in API a regression somewhere... But it could also be a 64bits issue not seen before :) Jerome Glisse HS^ľéXŹJ'˛Ţuź ŕ^ś×ŤJíÁŞŢ ßzˇ§qáäŚ×Śmęő÷mśÓNRjqkjwąĘ 7ŻzZ)éí.'Ţs'%xúÚrŘzŔ WŠĂŽ+Ţ7ŻzZ)éí1ŠÚ)ŕş#yËlM挹7Źś)[EMAIL PROTECTED] 0˛§˘o۹ǚąđëׯzYX§XŹ´:âuëŢXŹśË(şˇ ~ŕzwŰił˙ĺËl˛Ťqç莧zßĺËlţXŹś)ߣ÷kׯz
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
I suggest testing a 2.6.12 not a 2.6.13, i think something might be wrong with 2.6.13 (IIRC i see people complaining on lkml or on dri user) a change in API a regression somewhere... But it could also be a 64bits issue not seen before :) I'd appreciate if someone could test with 2.6.13-rc5-mm1 or -rc6-mm1 whenever it comes out... There is a chance we've broken 32/64 bit system on 2.6.13 but I hope not ... testing with 2.6.12 might be a good idea s well alright... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Hi, On Wednesday 10 of August 2005 11:53, you wrote: I suggest testing a 2.6.12 not a 2.6.13, i think something might be wrong with 2.6.13 (IIRC i see people complaining on lkml or on dri user) a change in API a regression somewhere... But it could also be a 64bits issue not seen before :) I'd appreciate if someone could test with 2.6.13-rc5-mm1 or -rc6-mm1 whenever it comes out... There is a chance we've broken 32/64 bit system on 2.6.13 but I hope not ... testing with 2.6.12 might be a good idea s well alright... Dave. Well, as I wrote in my previous post, unfortunately it does not work for me with 2.6.12 as well (2.6.12.3 nor 4), also I rebuilt 2.6.11. I'd gladly test it with 2.6.13-rc-mm if only it worked for me with previous kernels ;). Thanks, Michal P.S. I also disabled absolutely everything in security section of kernel config to make sure it has no effect, I was getting blank screen too. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Hi, Thanks for the hint. On Wednesday 10 of August 2005 13:43, you wrote: Hi, What is the dmesg output after X is terminated by the SIGKILL? I also am seeing X get killed the same way, and in dmesg it shows that the kernel killed it (see the messages with the subject r300 DRI killing X). Though I haven't narrowed the source of the problem down beyond it being something that was changed because of, during, or soon after the merge of the r300 driver into the Mesa and DRM CVS trees. Here is dmesg output: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Used old pci detect: framebuffer loaded mtrr: 0xb000,0x1000 overlaps existing 0xb000,0x800 X: Corrupted page table at address 2aaab51b3000 PGD 37996067 PUD 37977067 PMD 3653f067 PTE c25fd037 Bad pagetable: 000f [1] PREEMPT CPU 0 Modules linked in: radeon drm ipt_TOS ipt_REJECT ipt_LOG ipt_limit ip6table_filter ip6_tables ipt_state ipt_pkttype ipt_MARK ipt_owner ipt_recent ipt_iprange ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables w83627hf eeprom i2c_sensor i2c_isa parport_pc parport irtty_sir sir_dev irda floppy snd_via82xx gameport snd_ac97_codec snd_mpu401_uart snd_rawmidi i2c_viapro tuner cx8800 cx88xx i2c_algo_bit video_buf ir_common tveeprom v4l1_compat v4l2_common btcx_risc videodev tda9887 agpgart dm_mod sata_via libata usb_storage usbhid Pid: 12700, comm: X Not tainted 2.6.12.4 RIP: 0033:[2afce4c0] [2afce4c0] RSP: 002b:7faa8f78 EFLAGS: 00013283 RAX: 0080 RBX: 000b RCX: 2aaab51b3000 RDX: 2000 RSI: RDI: 2aaab51b3000 RBP: 007658f0 R08: R09: c25fd000 R10: 007455e0 R11: 00460b80 R12: 0002 R13: R14: 00765570 R15: 0002 FS: 2b184b00() GS:805f7c00() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2aaab51b3000 CR3: 379d6000 CR4: 06e0 Process X (pid: 12700, threadinfo 810037eaa000, task 810037a6d4c0) RIP [2afce4c0] RSP 7faa8f78 Michal --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: why no open source driver for NVIDIA/ATI
On Jul 28, 05 19:29:19 +0200, Roland Scheidegger wrote: R200 did not really have pixel shaders. They had a configurable pixel pipeline, that's different. Comparable to GeForce2, a little bit better. Looks better to me than GeForce3/4, really, if only for the dependant texture read. You nowadays indeed have (directx) games which have PS 1.4 (thus r200) as minimum, but won't work on GF3/4. GeForce3 didn't improve much here compared to GeForce2. You could have dependant texture read in GeForce3 as well (NV_texture_shader), but I think that the later R2xx were a little bit more flexible. The GeForce3 had 3D textures (except for an early sample we had at Unversity :-/ ), and IIRC this was before the Radeon7500. If the Radeon7500 has it, the radeon 7200 (radeon sdr/ddr as it was called) should have it too. And that was certainly way before geforce3. It seems to have it as well. I don't remember the release dates, though. I think I remember, that the OpenGL drivers exposed this feature on the GeForce first. Well - sort of. R300 still does not do IEEE computations in its pixel shader (I think R400 doesn't either), which gives you crappy results for GPGPU applications. True, but that's not really what these cards are intended for. R300 does nice fast fp24 calculations, with FX5 you could choose between really slow fp16 and even slower fp32 :-). Oh or you could choose quite fast int8... Sort of. Well, fp16 was quite ok. And on FX6 this is really fast now. Yep. They used to do good hardware. Have fallen behind a bit compared to GeForce6, but not much. Well, r520 should do fp32, longer shaders and what not. The chip's late though, we'll see. (is it only me or is this all slightly offtopic?) Yep, let's end it now :^) Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Here is dmesg output: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Used old pci detect: framebuffer loaded mtrr: 0xb000,0x1000 overlaps existing 0xb000,0x800 X: Corrupted page table at address 2aaab51b3000 PGD 37996067 PUD 37977067 PMD 3653f067 PTE c25fd037 Bad pagetable: 000f [1] PREEMPT I hope someone more knowledgable about amd64 will chime in - are we supposed to see those Corrupted page table at address 2aaab51b3000 messages ? What can cause this ? (I've never seen kernel driver causing anything like this, let alone a userspace program). Also, there was a similar report before: http://www.opensubscriber.com/message/dri-devel%40lists.sourceforge.net/1865882.html Additionally, google found this: http://softwareforums.intel.com/ids/board/print?board.id=14message.id=1099 (careful - this is a print form, so it will try to print when you are viewing the page) It shows up a very similar error but with Intel VTune analyzer, while using Linux 2.6.12. So it is possible that the problem is not with X or DRM but rather with the kernel itself. Michal, could you test 2.6.11 ? thank you ! Vladimir Dergachev --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Hi, On Wednesday 10 of August 2005 14:43, Vladimir Dergachev wrote: Here is dmesg output: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Used old pci detect: framebuffer loaded mtrr: 0xb000,0x1000 overlaps existing 0xb000,0x800 X: Corrupted page table at address 2aaab51b3000 PGD 37996067 PUD 37977067 PMD 3653f067 PTE c25fd037 Bad pagetable: 000f [1] PREEMPT I hope someone more knowledgable about amd64 will chime in - are we supposed to see those Corrupted page table at address 2aaab51b3000 messages ? What can cause this ? (I've never seen kernel driver causing anything like this, let alone a userspace program). Also, there was a similar report before: http://www.opensubscriber.com/message/dri-devel%40lists.sourceforge.net/186 5882.html Additionally, google found this: http://softwareforums.intel.com/ids/board/print?board.id=14message.id=1099 (careful - this is a print form, so it will try to print when you are viewing the page) It shows up a very similar error but with Intel VTune analyzer, while using Linux 2.6.12. So it is possible that the problem is not with X or DRM but rather with the kernel itself. Michal, could you test 2.6.11 ? it's the same with 2.6.11 (2.6.11.12 to be exact), just in case I built it with all security disabled (including default linux capabilities) and preemptive kernel (so PREEMPT has not been displayed, but behaviour remained the same). [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: PCI device 1002:4153 (ATI Technologies Inc) [drm] Used old pci detect: framebuffer loaded mtrr: 0xb000,0x1000 overlaps existing 0xb000,0x800 X: Corrupted page table at address 2aaab51b3000 PGD 3965a067 PUD 399d8067 PMD 38029067 PTE c20fd037 Bad pagetable: 000f [1] CPU 0 Modules linked in: radeon drm ipt_TOS ipt_REJECT ipt_LOG ipt_limit ip6table_filter ip6_tables ipt_state ipt_pkttype ipt_MARK ipt_owner ipt_recent ipt_iprange ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables w83627hf eeprom i2c_sensor i2c_isa parport_pc parport irtty_sir sir_dev irda floppy snd_via82xx snd_ac97_codec gameport snd_mpu401_uart snd_rawmidi i2c_viapro tuner cx8800 cx88xx i2c_algo_bit video_buf v4l1_compat v4l2_common btcx_risc videodev tda9887 agpgart dm_mod sata_via libata usb_storage usbhid Pid: 12684, comm: X Not tainted 2.6.11.12 RIP: 0033:[2afce4c0] [2afce4c0] RSP: 002b:7fffe358 EFLAGS: 00013283 RAX: 0080 RBX: 0006 RCX: 2aaab51b3000 RDX: 2000 RSI: RDI: 2aaab51b3000 RBP: 00765580 R08: R09: c20fd000 R10: 00745270 R11: 00460b80 R12: 0002 R13: R14: 00765200 R15: 0002 FS: 2b184b00() GS:805b09c0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2aaab51b3000 CR3: 3d67a000 CR4: 06e0 Process X (pid: 12684, threadinfo 81003dc3c000, task 810038bce130) RIP [2afce4c0] RSP 7fffe358 Michal --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Adam K Kirchhoff wrote: Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 Try this patch here: http://marc.theaimsgroup.com/?l=mesa3d-devm=112337787415898w=2 That should fix the issue. I believe it not only fixes it, but it's the right thing to do, mesa maps the gl vertex attrib functions (such as glNormal) to glVertexAttribNV functions somewhere in the display list code - and the dispatch offsets for these won't exist otherwise (unless you have a driver which claims to support NV_vertex_program). Someone might want to check this in (with a better comment...), I can't until next week. Roland --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Roland Scheidegger wrote: Adam K Kirchhoff wrote: Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 Try this patch here: http://marc.theaimsgroup.com/?l=mesa3d-devm=112337787415898w=2 That should fix the issue. I believe it not only fixes it, but it's the right thing to do, mesa maps the gl vertex attrib functions (such as glNormal) to glVertexAttribNV functions somewhere in the display list code - and the dispatch offsets for these won't exist otherwise (unless you have a driver which claims to support NV_vertex_program). Someone might want to check this in (with a better comment...), I can't until next week. Roland Roland, Thanks! That fixed the crahes for me. Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4031] Mach64: Mesa does not compile. /usr/bin/ld: cannot find -lEGL
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=4031 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG | --- Additional Comments From [EMAIL PROTECTED] 2005-08-11 05:00 --- I have done cvs up -dAP and a full build with the same result. Then, I deleted the whole CVS tree: I deleted Mesa, xc and drm and downloaded again the whole tree, then compiled and installed, and the fail was the same. I have found that if I delete the line SRC_DIRS = mesa from linux-dri-x86, then Mesa compiles without errors. This makes mach64_dri.so and also demodriver.so, libGLw.so.1.0.0, libglut.so.3.7.1, libGLU.so.1.3.060301, libGL.so.1.2, libEGL.so.1.0, libEGLdri.so.1.0 and other symlinks to these files. Should these files be installed also? If they must be installed, dri wiki building should be changed. I have an ATI Rage Mobility-M AGP 2X card in a Dell Inspiron 3700 and Mandrake-linux 10.1 -- 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. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH drm] sis and via security check for memory alloc.
Thomas Hellström wrote: Hi! Attached is a patch that stops a drm client from registering a fb / agp memory block under an arbitrary context handle, which will lead to heap memory leaks if the client dies. It also stops malicious clients from freeing other clients fb / agp memory blocks. Works fine with via, but it will break sis bsd, so I'll hold off with commiting. Could someone test on SiS hardware? /Thomas I'm commiting the security fix for VIA. SiS will have to be updated by someone having that hardware. /Thomas --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_CAS bug with x86_64
Alan Coopersmith wrote: I was wondering why ffb was even being built on x86_64. If it's referring to the board from Sun (which marketing called a Creator or Creator 3D), it was only ever made for the UPA bus (UltraSPARC Port Architecture), not PCI or any other common bus, and I've never seen a UPA bus outside of a SPARC machine. It's enabled in Mesa/configs/linux-dri, and I pasted the list over into my host.def to customize the list of drivers. I've left ffb there by mistake. ffb is also included on x86 and ia64 in DevelDriDrivers. Those drivers are only built when BuildDevelDRIDrivers is set. Today I must have been reading imake's configuration files for too long... Need some rest :-) -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa's internal use of NV_vertex_program entry points (was Re: IGP + DRI + xfce4 = Hang.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: Roland Scheidegger wrote: Try this patch here: http://marc.theaimsgroup.com/?l=mesa3d-devm=112337787415898w=2 That should fix the issue. I believe it not only fixes it, but it's the right thing to do, mesa maps the gl vertex attrib functions (such as glNormal) to glVertexAttribNV functions somewhere in the display list code - and the dispatch offsets for these won't exist otherwise (unless you have a driver which claims to support NV_vertex_program). Someone might want to check this in (with a better comment...), I can't until next week. This should all be shifted from relying on the NV extension to the ARB one, that might mean changing the display list code as well. The ARB extensions are pretty much central to the future development of Mesa and the drivers, while the NV ones will remain peripheral. In this particular case, we can't (without changing *lots* of code). The ARB attributes do not alias the fixed-function attributes, but the NV attributes do. Mesa is relying on the aliasing happening. I'm not sure what the right answer is here, but I'm open to suggestions. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC+o9QX1gOwKyEAw8RAi8VAJ4kRFZ2JTou/JD+kStDUmxmf2DP/ACePzy0 Vqa2w8wNyLUTmFysoEaXzq4= =uBco -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
