Re: [patches] Re: r300 radeon 9800 lockup
On Mon, 30 May 2005 20:31:24 -0400 Jonathan Bastien-Filiatrault [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai A) The first patch may help a little, but definitely doesn't eliminate the lockups. B) Huge regression. With both patches I get an immediate lockup when launching glxgears (before the window is even drawn). Adam Funny enough, two days ago, I played vegastrike for litterally _hours_ with my Radeon 9800 Pro, both patches applied, I restarted the game a couple times and I could not get it to lockup. However, the day after, I could not even start the game without causing a lockup. Looks like you did something good, keep up the great work. This is probably my fault if you updated local copy meanwhile. You can enable the old behaviour by commenting line #define CB_DPATH of r300_ioctl.c if its there. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3267] Rendering errors - Radeon 7500
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=3267 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 00:18 --- This does sound like an app bug. While I couldn't reproduce on an rv200 with foobillard 3.0a, I was able to produce similar problems by zooming way in on the cue ball, and there was obvious z fighting. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 initial PCI-express patch .. not working ...
Hi all,
I've written the initial code for PCI express for the X300 (patch
attached), it sets the registers up somewhat like the normal PCI gart
code, and like what fglrx seems to do as well...
Now my problem at the moment is I can't get fglrx to work on my X300 at
all either, it hangs... (XP works fine..), I'm going to install FC3 as
well as ubuntu just to get a second opinion :-)
I've also attached a patch to hw_script that reads the PCIE registers that
can be used with fglrx...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
Index: linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.4
diff -u -r1.4 drmP.h
--- linux-core/drmP.h 13 May 2005 18:30:46 - 1.4
+++ linux-core/drmP.h 31 May 2005 07:00:33 -
@@ -1025,6 +1025,11 @@
return pci_find_capability(dev-pdev, PCI_CAP_ID_AGP);
}
+static __inline__ int drm_device_is_pcie(drm_device_t *dev)
+{
+ return pci_find_capability(dev-pdev, PCI_CAP_ID_EXP);
+}
+
static __inline__ void drm_core_dropmap(struct drm_map *map)
{
}
Index: shared-core/drm_pciids.txt
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/drm_pciids.txt,v
retrieving revision 1.11
diff -u -r1.11 drm_pciids.txt
--- shared-core/drm_pciids.txt 4 Mar 2005 00:14:42 - 1.11
+++ shared-core/drm_pciids.txt 31 May 2005 07:00:34 -
@@ -62,6 +62,7 @@
0x1002 0x516A CHIP_R200 ATI Radeon Qj R200
0x1002 0x516B CHIP_R200 ATI Radeon Qk R200
0x1002 0x516C CHIP_R200 ATI Radeon Ql R200
+0x1002 0x5460 CHIP_RV350 ATI Radeon X300
0x1002 0x5834 CHIP_RS300|CHIP_IS_IGP ATI Radeon RS300 IGP
0x1002 0x5835 CHIP_RS300|CHIP_IS_IGP|CHIP_IS_MOBILITY ATI Radeon RS300
Mobility IGP
0x1002 0x5836 CHIP_RS300|CHIP_IS_IGP ATI Radeon RS300 IGP
Index: shared-core/radeon_cp.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_cp.c,v
retrieving revision 1.7
diff -u -r1.7 radeon_cp.c
--- shared-core/radeon_cp.c 19 Apr 2005 21:05:18 - 1.7
+++ shared-core/radeon_cp.c 31 May 2005 07:00:37 -
@@ -823,6 +823,12 @@
return RADEON_READ(RADEON_CLOCK_CNTL_DATA);
}
+static int RADEON_READ_PCIE(drm_radeon_private_t *dev_priv, int addr)
+{
+ RADEON_WRITE8(RADEON_PCIE_INDEX, addr 0xff);
+ return RADEON_READ(RADEON_PCIE_DATA);
+}
+
#if RADEON_FIFO_DEBUG
static void radeon_status(drm_radeon_private_t * dev_priv)
{
@@ -1231,11 +1237,35 @@
RADEON_ISYNC_CPSCRATCH_IDLEGUI));
}
+/* Enable or disable PCI-E GART on the chip */
+static void radeon_set_pciegart(drm_radeon_private_t * dev_priv, int on)
+{
+ u32 tmp = RADEON_READ_PCIE(dev_priv, RADEON_PCIE_TX_GART_CNTL);
+ if (on) {
+ RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_CNTL,
RADEON_PCIE_TX_GART_EN | RADEON_PCIE_TX_GART_UNMAPPED_ACCESS_DISCARD |
RADEON_PCIE_TX_GART_CHK_RW_VALID_EN);
+
+ RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_BASE,
dev_priv-bus_pci_gart);
+ RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_START_LO,
dev_priv-gart_vm_start);
+ RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_END_LO,
dev_priv-gart_vm_start
++ dev_priv-gart_size - 1);
+
+ RADEON_WRITE(RADEON_MC_AGP_LOCATION, 0xffc0); /* ?? */
+ } else {
+ RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_CNTL, tmp
~RADEON_PCIE_TX_GART_EN);
+ }
+}
+
/* Enable or disable PCI GART on the chip */
static void radeon_set_pcigart(drm_radeon_private_t * dev_priv, int on)
{
u32 tmp = RADEON_READ(RADEON_AIC_CNTL);
+ if (dev_priv-flags CHIP_IS_PCIE)
+ {
+ radeon_set_pciegart(dev_priv, on);
+ return;
+ }
+
if (on) {
RADEON_WRITE(RADEON_AIC_CNTL,
tmp | RADEON_PCIGART_TRANSLATE_EN);
@@ -2051,8 +2081,11 @@
if (drm_device_is_agp(dev))
dev_priv-flags |= CHIP_IS_AGP;
+ if (drm_device_is_pcie(dev))
+ dev_priv-flags |= CHIP_IS_PCIE;
+
DRM_DEBUG(%s card detected\n,
- ((dev_priv-flags CHIP_IS_AGP) ? AGP : PCI));
+ ((dev_priv-flags CHIP_IS_AGP) ? AGP : (((dev_priv-flags
CHIP_IS_PCIE) ? PCIE : PCI;
#if defined(__linux__)
/* Check if we need a reset */
Index: shared-core/radeon_drv.h
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_drv.h,v
retrieving revision 1.12
diff -u -r1.12 radeon_drv.h
--- shared-core/radeon_drv.h3 Mar 2005 04:40:21 - 1.12
+++ shared-core/radeon_drv.h31 May 2005 07:00:40 -
@@ -126,6 +126,7 @@
CHIP_SINGLE_CRTC = 0x0004UL,
Re: r300 bugs
Vladimir Dergachev wrote: On Mon, 30 May 2005, Bernhard Rosenkraenzer wrote: Hi, I've just tried out the r300 driver - works remarkably well for untested and broken code. :)) I've run into 2 bugs though: It doesn't work well if the display uses 16 bpp (24 bpp works perfectly) -- 3D in 16 bpp is pretty badly misrendered (sample attached; 2D works well w/ r300 DRI even at 16 bpp) -- mixed with a random section of the rest of the screen, wrong colors, and drawn way too large (but close enough to the expected output to recognize it). I don't think we ever focused on getting 16bpp right - having 32bpp working is fun enough :) Also, all of r300 and later cards have more than enough RAM for 32bpp modes. That said, it is probably just a matter of making sure some constants are set properly (like colorbuffer parameters), I don't think anything else in the driver is tied to that. If 16bpp isn't supported, the DDX and/or r300 client driver should be modified not to try, and just fall back to indirect rendering. Keith --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] [patches] debugging lockups
Hello everybody,
today's lockup-chasing wrapup follows :)
Two observations about the lockups I've been seeing:
(1) Lockups are more likely to occur when the ring buffer is filled with
packet2s for alignment (see the attached experimental
patch.drm-align-ring).
(2) Lockups are a lot less likely to occur when additional synchronisation
measures are taken (like waiting for the read pointer to catch up with the
write pointer after every ADVANCE_RING).
If we assume that the (most) lockups are caused by a race in memory
accesses, then both observations make sense: Filling the ring buffer with
packet2s causes the CP to request new batches from the ring buffer more
often, and waiting for the ring buffer to catch up means that less stuff
happens in parallel. Of course there may be a number of other
interpretations.
Another observation:
(3) On my system, lockups involving simple programs (like glxgears) are a
lot more likely to happen when multiple 3D clients are running in parallel.
In particular, starting glean while running glxgears means an almost
certain lockup, at least with the patch.remove-userspace-pacifiers that I
posted earlier. (The background for that patch was that fglrx never emits a
pacifier sequence in between 3D commands)
I have written a very unintrusive debugging facility for the DRM that
basically logs which parts of the code emit commands to the ring buffer.
When a lockup is detected, it prints this information out (via printk)
along with a dump of the relevant part of the ring buffer. I have attached
this patch, it is called patch.drm-debug-lockups-enabled (this logging
facility can be disabled at compile time via the RADEON_DEBUG_LOCKUPS
define in radeon_drv.h).
Using this patch, I have made another observation:
(4) All the lockups that happen for me occur when two cmdbuf ioctls are
processed immediately after another, without an idle ioctl or similar
inbetween.
So I have compared what our driver does at the boundary of 3D commands to
what fglrx does, and I've come up with the attached
patch.drm-cmdbuf-more-pacifiers, which adds an additional wait command to
the end of r300_do_cp_cmdbuf. Using this patch, glean no longer locks up
immediately when glxgears is running at the same time. Unfortunately, not
all lockups have gone away yet...
What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers,
and report if there are any regressions (I don't believe there are any)
and/or if it removes certain lockups you are seeing.
If you're feeling adventurous, I'd appreciate it if you could also try this
patch in combination with the patch.remove-userspace-pacifiers patch I
posted earlier, though this patch appears to be dangerous still (even
though I do not understand why).
cu,
Nicolai
Index: drm/shared-core/radeon_drv.h
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_drv.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 radeon_drv.h
--- drm/shared-core/radeon_drv.h 3 Mar 2005 04:40:21 - 1.12
+++ drm/shared-core/radeon_drv.h 31 May 2005 17:36:01 -
@@ -985,14 +985,37 @@ do { \
#define RING_LOCALS int write, _nr; unsigned int mask; u32 *ring;
+#define ALIGN_RING() do { \
+ int _nr = 32 - (dev_priv-ring.tail 31); \
+ int _write; \
+ if (dev_priv-ring.space = (_nr+1) * sizeof(u32)) { \
+ COMMIT_RING(); \
+ radeon_wait_ring( dev_priv, (_nr+1) * sizeof(u32) ); \
+ }\
+ _write = dev_priv-ring.tail; \
+ if (_write 1) { \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr--; \
+ }\
+ while( _nr = 2 ) { \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr -= 2; \
+ }\
+ dev_priv-ring.tail = _write; \
+} while (0)
+
#define BEGIN_RING( n ) do { \
+ ALIGN_RING(); /* TEST TEST */ \
if ( RADEON_VERBOSE ) { \
DRM_INFO( BEGIN_RING( %d ) in %s\n, \
n, __FUNCTION__ );\
}\
- if ( dev_priv-ring.space = (n) * sizeof(u32) ) { \
+ if ( dev_priv-ring.space = dev_priv-ring.size/2 /*(n+1) * sizeof(u32)*/ ) { \
COMMIT_RING(); \
- radeon_wait_ring( dev_priv, (n) * sizeof(u32) ); \
+ radeon_wait_ring( dev_priv, dev_priv-ring.size/2/*(n+1) * sizeof(u32)*/ ); \
}\
_nr = n; dev_priv-ring.space -= (n) * sizeof(u32); \
ring = dev_priv-ring.start; \
Index: drm/shared-core/radeon_cp.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_cp.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 radeon_cp.c
--- drm/shared-core/radeon_cp.c 19 Apr 2005 21:05:18 - 1.7
+++ drm/shared-core/radeon_cp.c 31 May 2005 19:29:50 -
@@ -846,6 +847,126 @@ static void
[Bug 2516] some rasterization fallbacks cause segfaults
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=2516 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 15:21 --- I can reproduce a similar backtrace on radeon and r200 using neverball, which is doing a rasterization fallback beacuse I'm running at 16bpp (no stencil). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214635360 (LWP 1346)] 0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386 386 a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride; (gdb) bt #0 0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386 #1 0xb7055a52 in _tnl_build_vertices (ctx=0x8110180, start=0, end=0, newinputs=4294967295) at tnl/t_vertex.c:408 #2 0xb704a066 in run_render (ctx=0x8110180, stage=0x830d314) at tnl/t_vb_render.c:295 #3 0xb70410b5 in _tnl_run_pipeline (ctx=0x8110180) at tnl/t_pipeline.c:159 #4 0xb6fba915 in r200WrapRunPipeline (ctx=0x8110180) at r200_state.c:2316 #5 0xb704640c in _tnl_playback_vertex_list (ctx=0x8110180, data=0x85e5198) at tnl/t_save_playback.c:209 #6 0xb6feccb3 in execute_list (ctx=0x8110180, list=135332224) at main/dlist.c:5679 #7 0xb6fef760 in _mesa_CallList (list=80) at main/dlist.c:6747 #8 0xb703a9e2 in neutral_CallList (i=0) at vtxfmt_tmp.h:301 -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2026] bzflag crashes R200 DRI
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=2026 --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 16:54 --- Attach your xorg.conf and Xorg.0.log? -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2497] glut menues are broken in sw-tnl mode
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=2497 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 16:53 --- This is also the case on many other drivers, and I think started to occur with the t_vertex transition. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2766] texgen GL_SPHERE_MAP should not cause a tcl fallback
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=2766 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 17:00 --- I've turned the fallback off, since it seems GL_SPHERE_MAP should work, and apparently works in some cases. I've confirmed that R200_LOCAL_VIEWER did fix texcyl (just drop it into the TCL_LIGHT_MODEL_CTL_0 of r200_state_init.c to see), though reading gl specs and ati specs, I can't come up with a reason why. Perhaps Michel could shed some light on this? -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
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=2516 --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 17:09 --- (In reply to comment #9) I can reproduce a similar backtrace on radeon and r200 using neverball I'll commit the fix if you don't come up with a better one, the radeon driver is only affected since it was converted to t_vertex. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
removing radeon_acknowledge_irqs hack..
In radeon_irq.c:radeon_wait_irq There is a comment /* This is a hack to work around mysterious freezes on certain * systems: */ radeon_acknowledge_irqs(dev_priv); On my 7500 system I've been seeing mysterious hangs after a week or so running, and I've removed this hack from my system and my hangs seem to have gone away, I've talked to Keith about it and he can't remember exactly what it fixed but he remembered never producing it on his own system, and it is a bad idea IMHO.. I'm mainly sending this mail as I can guarantee about 5 mins after I send one of my machines wil hang :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bugs
is fun enough :) Also, all of r300 and later cards have more than enough RAM for 32bpp modes. That said, it is probably just a matter of making sure some constants are set properly (like colorbuffer parameters), I don't think anything else in the driver is tied to that. If 16bpp isn't supported, the DDX and/or r300 client driver should be modified not to try, and just fall back to indirect rendering. It think it would be better to put one of the WARN_ONCE messages about the fact that 16bpp is broken and needs to be fixed. Things that are broken and easy to fix are best exposed. best Vladimir Dergachev Keith --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
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=2516 --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 17:59 --- I was just noting the ability to reproduce, not saying something either way about the patch. I haven't looked into the patch. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
