Hi. I am posting a warning I got from todays git...
Should I open a new bug?
Τhis is on a Mobility X2300
[ 212.042277] [ cut here ]
[ 212.042317] WARNING: at /home/kernel-
ppa/mainline/build/drivers/gpu/drm/radeon/radeon_fence.c:159
radeon_fence_signaled+0xb3/0xd0 [r
On Thursday 16 April 2009 12:29:44 pm Jin, Gordon wrote:
> Roland Scheidegger wrote on Thursday, April 16, 2009 8:52 AM:
> I just fixed the link. Please give it a retry.
>
> Thanks
> Gordon
> ___
> xorg mailing list
> x...@lists.freedesktop.org
> http://l
Hi everybody.
I think that
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=da1d9d97959bd1e4c8e359d28b4fd6cafdd4168a
broke line widths for r300. If I change the width to 3.0 for example and the
back to 1.0 all lines are renderer with width 3.0.
Regards
Papadakos Panagiotis
--
Yep, I think it is OK!
On Friday 09 March 2007 10:46, Michel Dänzer wrote:
> On Thu, 2007-03-08 at 19:07 +0200, Panagiotis Papadakos wrote:
> > On Thursday 08 March 2007 17:05, Michel Dänzer wrote:
> > > Any idea what's going on? The only situation where radeonSetClip
On Thursday 08 March 2007 17:05, Michel Dänzer wrote:
>
> Any idea what's going on? The only situation where radeonSetCliprects
> doesn't get called from radeonMakeCurrent is if neither the drawable nor
> its stamp has changed...
We have to call radeonSetCliprects(radeon), before
r300UpdateViewp
I still get invalid reads with your latest patch.
On Thursday 08 March 2007 15:42, Michel Dänzer wrote:
> On Thu, 2007-03-08 at 14:31 +0100, Michel Dänzer wrote:
> > On Thu, 2007-03-08 at 14:25 +0200, Panagiotis Papadakos wrote:
> > > > Calling radeonSetCliprects when stamp!
> Calling radeonSetCliprects when stamp!=lastStamp also helps!
Sorry meant radeon->lastStamp != driDrawPriv->lastStamp and
radeon->lastStamp != driReadPriv->lastStamp.
-
Take Surveys. Earn Cash. Influence the Future of IT
J
On Thursday 08 March 2007 12:12, Michel Dänzer wrote:
> Does calling radeonSetCliprects unconditionally before
> _mesa_make_current help? I don't see a way for radeonMakeCurrent to be
> sure DoBindContext didn't update the cliprects.
Yep it helps. Calling radeonSetCliprects when stamp!=lastStamp
The problem is that I still get invalid reads when going from fullscreen mode
to window mode for the first time, with my OSG application.
On Wednesday 07 March 2007 19:10, Michel Dänzer wrote:
> On Wed, 2007-03-07 at 19:02 +0200, Panagiotis Papadakos wrote:
> > On Friday 02 March 2
On Friday 02 March 2007 16:41, Michel Dänzer wrote:
> On Mon, 2007-02-26 at 07:09 +0200, Panagiotis Papadakos wrote:
> > Well I think I have the correct patch for this.
>
> I'm afraid not; the test modification is incorrect. The test is an
> optimization to avoid doing un
On Thursday 01 March 2007 20:11, Aapo Tahkola wrote:
> On Thu, 1 Mar 2007 17:46:12 +0200
>
> Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> > Diving more into the code, I also found weird how the scratch cmd
> > packet is build in radeon_mm_use, in radeon_mm.c. I thi
Diving more into the code, I also found weird how the scratch cmd packet
is build in radeon_mm_use, in radeon_mm.c. I think it should be like in the
attached patch.
On Wednesday 28 February 2007 22:33, Panagiotis Papadakos wrote:
> Updated patch. Fix a check.
>
> On Tuesday 27 Februar
I can't reproduce this error with the scratch patch I sent earlier. ;-)
On Thursday 01 February 2007 20:08, Panagiotis Papadakos wrote:
> My application sometimes crashes with the following message (most of the
> times when I run it with valgrind):
> drmRadeonCmdBuffer: -22 (exiti
Updated patch. Fix a check.
On Tuesday 27 February 2007 23:49, Panagiotis Papadakos wrote:
> Hope this patch is OK.
>
> With it I no more get infinite messages like:
>
> Feb 27 15:48:39 localhost kernel: [drm:r300_do_cp_cmdbuf] R300_CMD_SCRATCH
> Feb 27 15:48:39 localhost last
Hope this patch is OK.
With it I no more get infinite messages like:
Feb 27 15:48:39 localhost kernel: [drm:r300_do_cp_cmdbuf] R300_CMD_SCRATCH
Feb 27 15:48:39 localhost last message repeated 2 times
Feb 27 15:48:39 localhost kernel: [drm:r300_do_cp_cmdbuf] END
Feb 27 15:48:39 localhost kernel: [
count?
On Friday 02 February 2007 19:36, Panagiotis Papadakos wrote:
> Well this patch is not correct since it leads to memory leaks, probably due
> to succeeding calls to dri_interface->getDrawableInfo. So I created the
> attached patch, but again valgrind warns for invalid reads.
>
On Friday 02 February 2007 12:01, Michel Dänzer wrote:
> Hmm, I think this could only happen with several file descriptors
> using the same DRM context ID. Is your application multithreaded?
No, my application is not multithreaded.
>
> > This is using r300 driver and aiglx.
>
> FWIW, does disablin
01 February 2007 19:19, Panagiotis Papadakos wrote:
> Checking with valgrind I got some invalid reads. The message was like the
> following:
>
> ==6988== Invalid read of size 4
> ==6988==at 0x4B3C7FD: intersect_rect (radeon_state.c:61)
> ==6988==by 0x4B3C9DA: rad
My application sometimes crashes with the following message (most of the times
when I run it with valgrind):
drmRadeonCmdBuffer: -22 (exiting)
And in dmesg I get the following:
[drm:radeon_cp_cmdbuf] *ERROR* radeon_cp_cmdbuf called without lock held,
held -2147483648 owner d0297cc0 c7f35240
Th
Checking with valgrind I got some invalid reads. The message was like the
following:
==6988== Invalid read of size 4
==6988==at 0x4B3C7FD: intersect_rect (radeon_state.c:61)
==6988==by 0x4B3C9DA: radeonRecalcScissorRects (radeon_state.c:108)
==6988==by 0x4B3CAEC: radeonUpdateScissor (
We don't free XRectangle *xrects memory.
Patch attached.
--
Papadakos Panagiotis
--- src/glx/x11/glxext.c 2007-02-01 14:39:37.0 +0200
+++ src/glx/x11/glxext_new.c 2007-02-01 14:38:35.0 +0200
@@ -758,6 +758,7 @@
xrects[i].height = rects[i].y2 - rects[i].y1;
}
region = XF
Also I forgot to say that I got a lockup again when I tried to switch to a
VT with the previous patch and also that I believe that with 2.5.6X
kernels I get lockups sooner, than with 2.4.X.
Regards
Panagiotis Papadakos
On Sat, 5 Apr 2003, Panagiotis Papadakos wrote:
> Could this b
using at the moment to just try and test it?
My system is an Athlon 600, on an ASUS K7V with KX133, Matrox G400 and a
Live!
Regards
Panagiotis Papadakos
On Sat, 4 Apr 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Fre, 2003-04-04 at 22:38, Eric Anholt wrote:
> > On Fri, 2003-04-04
Cleanup DMA */
Regards
Panagiotis Papadakos
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://cli
I have the same problem with the introduction of quake3 (it renders only
the firt frame), using the latest Xfree86-CVS with Mesa-4.0.2.
So this is not a bug of drm-command.
Regards
Panagiotis Papadakos
___
Dri-devel mailing list
[EMAIL
frame and then freezes, until it is over and then it renders the
menu which works as expected.
Panagiotis Papadakos
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
ought maybe we don't have enough memory...
Panagiotis Papadakos
On Mon, 28 Jan 2002, Lynn Quam wrote:
> I tried your suggested patches to lib/GL/mesa/src/drv/mga/mgatexmem.c.
> I still occasionally get the message:
>
> Couldn't alloc placeholder sz 4 ofs 8000
A better patch without whitespace changes...
--- lib/GL/mesa/src/drv/mga/mgatexmem.c Sun Jan 27 12:59:37 2002
+++ lib/GL/mesa/src/drv/mga/mymgatexmem.c Sun Jan 27 13:12:48 2002
@@ -254,8 +254,18 @@
idx != MGA_NR_TEX_REGIONS && nr < MGA_NR_TEX_REGIONS ;
idx = sarea->texList[h
I had the same problem with a G400 when I was using stereo with the
Maverik lib.So I tried to find differences between the radeon_texmem.c and
mgatexmem.c.And this is a small patch which has solved many of my
problems.No my screen won't lock up and stereo views will work.I really
don't know nothin
29 matches
Mail list logo
