2.6.33-rc8-git latest radeon warning
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 [radeon]() [ 212.042320] Hardware name: VGN-CR21Z_R [ 212.042322] Querying an unemited fence : 88002fb03e00 ! [ 212.042324] Modules linked in: binfmt_misc ppdev snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep sbp2 arc4 snd_pcm_oss snd_mixer_oss snd_pcm pcmcia uvcvideo joydev snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi tifm_7xx1 videodev iwlagn v4l1_compat yenta_socket iwlcore tifm_core snd_seq_midi_event rsrc_nonstatic v4l2_compat_ioctl32 snd_seq pcmcia_core psmouse lp parport serio_raw btusb sony_laptop video intel_agp output snd_timer snd_seq_device snd fbcon tileblit mac80211 font soundcore bitblit cfg80211 snd_page_alloc softcursor usbhid ohci1394 radeon ttm ieee1394 r8169 mii drm_kms_helper drm i2c_algo_bit [ 212.042368] Pid: 3277, comm: Xorg Not tainted 2.6.33-999-generic #201002191003 [ 212.042370] Call Trace: [ 212.042386] [a00ddd13] ? radeon_fence_signaled+0xb3/0xd0 [radeon] [ 212.042392] [8105a237] warn_slowpath_common+0x87/0xb0 [ 212.042395] [8105a2e4] warn_slowpath_fmt+0x64/0x70 [ 212.042410] [a00de862] ? radeon_ttm_backend_bind+0x32/0xa0 [radeon] [ 212.042415] [8153fc79] ? _raw_spin_lock+0x9/0x10 [ 212.042423] [a009d4e5] ? ttm_bo_handle_move_mem+0x145/0x310 [ttm] [ 212.042430] [a009f028] ? ttm_bo_move_buffer+0x108/0x120 [ttm] [ 212.042444] [a00ddd13] radeon_fence_signaled+0xb3/0xd0 [radeon] [ 212.042458] [a00ddd67] radeon_fence_wait+0x37/0x360 [radeon] [ 212.042462] [8111f8d9] ? __slab_alloc+0xd9/0x240 [ 212.042477] [a00de670] ? radeon_fence_create+0xd0/0x130 [radeon] [ 212.042493] [a00f1f4a] radeon_ib_get+0x14a/0x210 [radeon] [ 212.042510] [a00f33c4] radeon_cs_ioctl+0x94/0x1e0 [radeon] [ 212.042514] [81540093] ? _lock_kernel+0x53/0xa0 [ 212.042529] [a000bb34] drm_ioctl+0x344/0x450 [drm] [ 212.042545] [a00f3330] ? radeon_cs_ioctl+0x0/0x1e0 [radeon] [ 212.042552] [81030899] ? default_spin_lock_flags+0x9/0x10 [ 212.042555] [8153fcaf] ? _raw_spin_lock_irqsave+0x2f/0x50 [ 212.042559] [8113b4f5] vfs_ioctl+0x35/0xc0 [ 212.042562] [8113baf7] do_vfs_ioctl+0x67/0x1e0 [ 212.042565] [8113bcf2] sys_ioctl+0x82/0xa0 [ 212.042571] [81009f02] system_call_fastpath+0x16/0x1b [ 212.042573] ---[ end trace b7fde20bafc0e95c ]--- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel(r) G45 Programmer's Reference Manual
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://lists.freedesktop.org/mailman/listinfo/xorg The link still does not work! Regards Panagiotis -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 line width problem
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 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 radeonSetCliprects doesn't get called from radeonMakeCurrent is if neither the drawable nor its stamp has changed... We have to call radeonSetCliprects(radeon), before r300UpdateViewportOffset(radeon-glCtx). Ah right, like this? -- Papadakos Panagiotis - 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 also helps! Regards Papadakos Panagiotis - 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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!=lastStamp also helps! Sorry meant radeon-lastStamp != driDrawPriv-lastStamp That'll usually be fine, but in theory the stamps could be identical when a different drawable was bound previously. How does this patch look? Or how about one that actually compiles and doesn't crash... -- Papadakos Panagiotis - 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 r300UpdateViewportOffset(radeon-glCtx). -- Papadakos Panagiotis - 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 unnecessary work when the context is already up to date wrt the drawables passed in and doesn't have anything to do with the stamps. Well I think we should do this, because __driUtilUpdateDrawableInfo, is called when lastStamp != stamp, and although the drawables have not changed, we get new cliprects. So we have to call radeonSetCliprects, else we point to memory freed in DoBindContext. -- Papadakos Panagiotis - 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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 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 unnecessary work when the context is already up to date wrt the drawables passed in and doesn't have anything to do with the stamps. Well I think we should do this, because __driUtilUpdateDrawableInfo, is called when lastStamp != stamp, and although the drawables have not changed, we get new cliprects. So we have to call radeonSetCliprects, else we point to memory freed in DoBindContext. Right, just your test modification was wrong. This turned out to also fix issues with apps that don't call glViewport by default, so I pushed something based on it in the meantime, see http://bugs.freedesktop.org/show_bug.cgi?id=9876 . Thanks. -- Papadakos Panagiotis - 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: [PATCH] r300_scratch in r300_cmdbuf.c is broken
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 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 message repeated 2 times
Feb 27 15:48:39 localhost kernel: [drm:r300_do_cp_cmdbuf] END
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538,
cmd=0xc0046456, nr=0x56, dev 0xe200, auth=1 Feb 27 15:48:39 localhost
kernel:
[drm:drm_ioctl] pid=3538, cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb
27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538,
cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost
kernel:
[drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538,
cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost
kernel:
[drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538,
cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost
kernel:
[drm:drm_ioctl] ret = fffc
--
Papadakos Panagiotis
diff --git a/src/mesa/drivers/dri/r300/radeon_mm.c b/src/mesa/drivers/dri/r300/radeon_mm.c
index f86a1b4..25f4f32 100644
--- a/src/mesa/drivers/dri/r300/radeon_mm.c
+++ b/src/mesa/drivers/dri/r300/radeon_mm.c
@@ -295,7 +295,7 @@ static void emit_lin_cp(r300ContextPtr r
void radeon_mm_use(r300ContextPtr rmesa, int id)
{
- uint64_t ull;
+ //uint64_t ull;
#ifdef MM_DEBUG
fprintf(stderr, %s: %d at age %x\n, __FUNCTION__, id, radeonGetAge((radeonContextPtr)rmesa));
#endif
@@ -338,23 +338,27 @@ void radeon_mm_use(r300ContextPtr rmesa,
rmesa-rmm-u_list[id].size);
}*/
#endif
+ LOCK_HARDWARE(rmesa-radeon); /* Protect from DRM. */
+ rmesa-rmm-u_list[id].h_pending ++;
+ UNLOCK_HARDWARE(rmesa-radeon);
- cmd = (drm_r300_cmd_header_t *)r300AllocCmdBuf(rmesa, 2 + sizeof(ull) / 4, __FUNCTION__);
+ cmd = (drm_r300_cmd_header_t *)r300AllocCmdBuf(rmesa, 4, __FUNCTION__);
cmd[0].scratch.cmd_type = R300_CMD_SCRATCH;
cmd[0].scratch.reg = RADEON_MM_SCRATCH;
cmd[0].scratch.n_bufs = 1;
cmd[0].scratch.flags = 0;
- cmd ++;
+/* cmd ++;
ull = (uint64_t)(intptr_t)rmesa-rmm-u_list[id].age;
_mesa_memcpy(cmd, ull, sizeof(ull));
cmd += sizeof(ull) / 4;
- cmd[0].u = /*id*/0;
-
- LOCK_HARDWARE(rmesa-radeon); /* Protect from DRM. */
- rmesa-rmm-u_list[id].h_pending ++;
- UNLOCK_HARDWARE(rmesa-radeon);
+ *///cmd[0].u = /*id*/0;
+
+ cmd[1].u = (uint32_t)(rmesa-rmm-u_list[id].age);
+ cmd[2].u = (uint32_t)(rmesa-rmm-u_list[id].h_pending);
+ cmd[3].u = /*id*/0;
+
}
unsigned long radeon_mm_offset(r300ContextPtr rmesa, int id)
-
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: [PATCH] r300_scratch in r300_cmdbuf.c is broken
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 think it should
be like in the attached patch.
This patch will break 64 bit systems. It only works on your system
because drm cuts 32 bits off the pointer.
This is what drm expects to see:
64_bit_pointer
for every buffer
32_bit_index
Thus, rmesa-rmm-u_list[id].age is at 64_bit_pointer[32_bit_index] .
Since age and h_pending go in pairs, rmesa-rmm-u_list[id].h_pending
is at 64_bit_pointer[32_bit_index + 1] .
Hope this clears out things a bit.
Yep. I think you are right.
Two questions though:
1) Should we increment h_pending, before memcpy to the buf?
(Is there any way that the drm reads the old value?)
2) Could you also see the attached patch, for the drm r300_scratch?
I think that the logic is wrong. Before the loop, you increment the buf,
8 bytes, although you should already be reading age and h_pending,
since the outer while loop removes the head.
Somehow all the loop seems a bit weird to me.
P.S.
Before applying this patch I was getting many messages like this one:
Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1
Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] ret = fffc
which I have not seen after applying this patch.
Thanks for your time.
diff --git a/shared-core/r300_cmdbuf.c b/shared-core/r300_cmdbuf.c
index 0c04b5f..09b4a35 100644
--- a/shared-core/r300_cmdbuf.c
+++ b/shared-core/r300_cmdbuf.c
@@ -720,10 +720,10 @@ static int r300_scratch(drm_radeon_priva
drm_r300_cmd_header_t header)
{
u32 *ref_age_base;
- u32 i, buf_idx, h_pending;
+ u32 i, h_pending;
RING_LOCALS;
- if (cmdbuf-bufsz sizeof(uint64_t) + header.scratch.n_bufs * sizeof(buf_idx) ) {
+ if (cmdbuf-bufsz header.scratch.n_bufs * sizeof(uint64_t) + sizeof(u32)) {
return DRM_ERR(EINVAL);
}
@@ -732,42 +732,41 @@ static int r300_scratch(drm_radeon_priva
}
dev_priv-scratch_ages[header.scratch.reg] ++;
-
+
ref_age_base = (u32 *)(unsigned long)*((uint64_t *)cmdbuf-buf);
-
- cmdbuf-buf += sizeof(uint64_t);
- cmdbuf-bufsz -= sizeof(uint64_t);
-
+
for (i=0; i header.scratch.n_bufs; i++) {
- buf_idx = *(u32 *)cmdbuf-buf;
- buf_idx *= 2; /* 8 bytes per buf */
-
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
+
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
return DRM_ERR(EINVAL);
}
-
- if (DRM_COPY_FROM_USER(h_pending, ref_age_base + buf_idx + 1, sizeof(u32))) {
+
+ if (DRM_COPY_FROM_USER(h_pending, ref_age_base + i * 2 + 1, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
-
+
if (h_pending == 0) {
- return DRM_ERR(EINVAL);
+ return DRM_ERR(EINVAL);
}
-
+
h_pending--;
-
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx + 1, h_pending, sizeof(u32))) {
+
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2 + 1, h_pending, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
-
- cmdbuf-buf += sizeof(buf_idx);
- cmdbuf-bufsz -= sizeof(buf_idx);
+
+ /* 8 bytes per buf */
+ cmdbuf-buf += sizeof(uint64_t);
+ cmdbuf-bufsz -= sizeof(uint64_t);
}
BEGIN_RING(2);
OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG0 + header.scratch.reg * 4, 0 ) );
OUT_RING( dev_priv-scratch_ages[header.scratch.reg] );
ADVANCE_RING();
+
+ cmdbuf-buf += sizeof(u32);
+ cmdbuf-bufsz -= sizeof(u32);
return 0;
}
-
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: [PATCH] r300_scratch in r300_cmdbuf.c is broken
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 message repeated 2 times
Feb 27 15:48:39 localhost kernel: [drm:r300_do_cp_cmdbuf] END
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0xc0046456,
nr=0x56, dev 0xe200, auth=1 Feb 27 15:48:39 localhost kernel:
[drm:drm_ioctl] pid=3538, cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb
27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost kernel:
[drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost kernel:
[drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:39 localhost kernel:
[drm:drm_ioctl] ret = fffc
--
Papadakos Panagiotis
diff --git a/shared-core/r300_cmdbuf.c b/shared-core/r300_cmdbuf.c
index 0c04b5f..7800545 100644
--- a/shared-core/r300_cmdbuf.c
+++ b/shared-core/r300_cmdbuf.c
@@ -720,10 +720,10 @@ static int r300_scratch(drm_radeon_priva
drm_r300_cmd_header_t header)
{
u32 *ref_age_base;
- u32 i, buf_idx, h_pending;
+ u32 i, h_pending;
RING_LOCALS;
- if (cmdbuf-bufsz sizeof(uint64_t) + header.scratch.n_bufs * sizeof(buf_idx) ) {
+ if (cmdbuf-bufsz header.scratch.n_bufs * sizeof(uint64_t) + sizeof(u32)) {
return DRM_ERR(EINVAL);
}
@@ -732,21 +732,17 @@ static int r300_scratch(drm_radeon_priva
}
dev_priv-scratch_ages[header.scratch.reg] ++;
-
+
ref_age_base = (u32 *)(unsigned long)*((uint64_t *)cmdbuf-buf);
- cmdbuf-buf += sizeof(uint64_t);
- cmdbuf-bufsz -= sizeof(uint64_t);
-
for (i=0; i header.scratch.n_bufs; i++) {
- buf_idx = *(u32 *)cmdbuf-buf;
- buf_idx *= 2; /* 8 bytes per buf */
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
+
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
return DRM_ERR(EINVAL);
}
- if (DRM_COPY_FROM_USER(h_pending, ref_age_base + buf_idx + 1, sizeof(u32))) {
+ if (DRM_COPY_FROM_USER(h_pending, ref_age_base + i * 2 + 1, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
@@ -756,18 +752,21 @@ static int r300_scratch(drm_radeon_priva
h_pending--;
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx + 1, h_pending, sizeof(u32))) {
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2 + 1, h_pending, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
- cmdbuf-buf += sizeof(buf_idx);
- cmdbuf-bufsz -= sizeof(buf_idx);
+ cmdbuf-buf += sizeof(uint64_t);
+ cmdbuf-bufsz -= sizeof(uint64_t);
}
BEGIN_RING(2);
OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG0 + header.scratch.reg * 4, 0 ) );
OUT_RING( dev_priv-scratch_ages[header.scratch.reg] );
ADVANCE_RING();
+
+ cmdbuf-buf += sizeof(u32);
+ cmdbuf-bufsz -= sizeof(u32);
return 0;
}
-
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: drm:radeon_cp_cmdbuf] *ERROR* radeon_cp_cmdbuf called without lock held problem
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 (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 This is using r300 driver and aiglx. -- Papadakos Panagiotis - 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
[PATCH] r300_scratch in r300_cmdbuf.c is broken
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: [drm:drm_ioctl] pid=3538, cmd=0xc0046456,
nr=0x56, dev 0xe200, auth=1
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457,
nr=0x57, dev 0xe200, auth=1
Feb 27 15:48:39 localhost kernel: [drm:drm_ioctl] ret = fffc
--
Papadakos Panagiotis
diff --git a/shared-core/r300_cmdbuf.c b/shared-core/r300_cmdbuf.c
index 0c04b5f..0e10689 100644
--- a/shared-core/r300_cmdbuf.c
+++ b/shared-core/r300_cmdbuf.c
@@ -720,10 +720,10 @@ static int r300_scratch(drm_radeon_priva
drm_r300_cmd_header_t header)
{
u32 *ref_age_base;
- u32 i, buf_idx, h_pending;
+ u32 i, h_pending;
RING_LOCALS;
- if (cmdbuf-bufsz sizeof(uint64_t) + header.scratch.n_bufs * sizeof(buf_idx) ) {
+ if (cmdbuf-bufsz header.scratch.n_bufs * sizeof(uint64_t)) {
return DRM_ERR(EINVAL);
}
@@ -732,21 +732,17 @@ static int r300_scratch(drm_radeon_priva
}
dev_priv-scratch_ages[header.scratch.reg] ++;
-
+
ref_age_base = (u32 *)(unsigned long)*((uint64_t *)cmdbuf-buf);
- cmdbuf-buf += sizeof(uint64_t);
- cmdbuf-bufsz -= sizeof(uint64_t);
-
for (i=0; i header.scratch.n_bufs; i++) {
- buf_idx = *(u32 *)cmdbuf-buf;
- buf_idx *= 2; /* 8 bytes per buf */
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
+
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2, dev_priv-scratch_ages[header.scratch.reg], sizeof(u32))) {
return DRM_ERR(EINVAL);
}
- if (DRM_COPY_FROM_USER(h_pending, ref_age_base + buf_idx + 1, sizeof(u32))) {
+ if (DRM_COPY_FROM_USER(h_pending, ref_age_base + i * 2 + 1, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
@@ -756,18 +752,21 @@ static int r300_scratch(drm_radeon_priva
h_pending--;
- if (DRM_COPY_TO_USER(ref_age_base + buf_idx + 1, h_pending, sizeof(u32))) {
+ if (DRM_COPY_TO_USER(ref_age_base + i * 2 + 1, h_pending, sizeof(u32))) {
return DRM_ERR(EINVAL);
}
- cmdbuf-buf += sizeof(buf_idx);
- cmdbuf-bufsz -= sizeof(buf_idx);
+ cmdbuf-buf += sizeof(uint64_t);
+ cmdbuf-bufsz -= sizeof(uint64_t);
}
BEGIN_RING(2);
OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG0 + header.scratch.reg * 4, 0 ) );
OUT_RING( dev_priv-scratch_ages[header.scratch.reg] );
ADVANCE_RING();
+
+ cmdbuf-buf += sizeof(u32);
+ cmdbuf-bufsz -= sizeof(u32);
return 0;
}
-
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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
Well I think I have the correct patch for this. We should call
radeonSetCliprects inside radeonMakeCurrent to update to
the new pClipRects whenever lastStamps change.
Probably this should also be applied to r200. Haven't seen for other drivers.
Comments?
P.S.
Should I try to get an account?
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.
Anyone understands why?
Thanks
P.S. Sorry but I am new to the code!
On Thursday 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: radeonRecalcScissorRects (radeon_state.c:108)
==6988==by 0x4B3CAEC: radeonUpdateScissor (radeon_state.c:131)
==6988==by 0x4B3CD04: radeonEnable (radeon_state.c:205)
==6988==by 0x4B4B1C1: r300Enable (r300_state.c:542)
==6988==by 0x4D13827: _mesa_set_enable (enable.c:956)
==6988==by 0x4D138A6: _mesa_Enable (enable.c:971)
==6988==by 0x4769879: glEnable (glapitemp.h:1160)
==6988==by 0x4613A5F:
osgUtil::RenderStage::drawImplementation(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988==by
0x4607658: osgUtil::RenderBin::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988==by
0x46133BC: osgUtil::RenderStage::drawInner(osg::RenderInfo,
osgUtil::RenderLeaf*, bool) (in /usr/lib/libosgUtil.so) ==6988==by
0x4612E6C: osgUtil::RenderStage::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988== Address
0x4AF585C is 4 bytes inside a block of size 8 free'd ==6988==at
0x402303F: free (vg_replace_malloc.c:233)
==6988==by 0x4BAF503: _mesa_free (imports.c:93)
==6988==by 0x4B2FF84: __driUtilUpdateDrawableInfo (dri_util.c:430)
==6988==by 0x4B2FD46: DoBindContext (dri_util.c:339)
==6988==by 0x4B2FF00: driBindContext (dri_util.c:383)
==6988==by 0x4735921: BindContextWrapper (glxext.c:1620)
==6988==by 0x4735A53: MakeContextCurrent (glxext.c:1674)
==6988==by 0x4735D7C: glXMakeCurrent (glxext.c:1796)
==6988==by 0x47D8BB3: Producer::RenderSurface::makeCurrent(bool) (in
/usr/lib/libProducer.so) ==6988==by 0x47DEEC6:
Producer::Camera::_frame(bool) (in /usr/lib/libProducer.so) ==6988==
by 0x47DF75F: Producer::Camera::frame(bool) (in /usr/lib/libProducer.so)
==6988==by 0x47E2589: Producer::CameraGroup::_singleThreadedFrame()
(in /usr/lib/libProducer.so)
So I searched a bit, and I created the following patch, which touches
src/mesa/drivers/dri/common/dri_util.c, and more specifically
__driUtilUpdateDrawableInfo, calling _mesa_free for pdp-pClipRects and
pdp-pBackClipRects only inside if.
Does this look sane?
Valgrind does not warn anymore.
--
Papadakos Panagiotis
diff --git a/src/mesa/drivers/dri/r300/radeon_context.c b/src/mesa/drivers/dri/r300/radeon_context.c
index 3a6bde8..10a8d35 100644
--- a/src/mesa/drivers/dri/r300/radeon_context.c
+++ b/src/mesa/drivers/dri/r300/radeon_context.c
@@ -52,6 +52,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DE
#include radeon_reg.h
#include r300_state.h
+#include radeon_state.h
#include utils.h
#include vblank.h
@@ -272,13 +273,15 @@ GLboolean radeonMakeCurrent(__DRIcontext
radeon-vbl_seq);
}
- if (radeon-dri.drawable != driDrawPriv ||
- radeon-dri.readable != driReadPriv) {
+ if(radeon-lastStamp != driDrawPriv-lastStamp ||
+ radeon-lastStamp != driReadPriv-lastStamp) {
radeon-dri.drawable = driDrawPriv;
radeon-dri.readable = driReadPriv;
- r300UpdateWindow(radeon-glCtx);
- r300UpdateViewportOffset(radeon-glCtx);
+ radeonSetCliprects(radeon);
+ radeon-lastStamp = driDrawPriv-lastStamp;
+ r300UpdateWindow( radeon-glCtx );
+ r300UpdateViewportOffset( radeon-glCtx );
}
_mesa_make_current(radeon-glCtx,
diff --git a/src/mesa/drivers/dri/r300/radeon_lock.c b/src/mesa/drivers/dri/r300/radeon_lock.c
-
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: Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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.
Anyone understands why?
Thanks
P.S. Sorry but I am new to the code!
On Thursday 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: radeonRecalcScissorRects (radeon_state.c:108)
==6988==by 0x4B3CAEC: radeonUpdateScissor (radeon_state.c:131)
==6988==by 0x4B3CD04: radeonEnable (radeon_state.c:205)
==6988==by 0x4B4B1C1: r300Enable (r300_state.c:542)
==6988==by 0x4D13827: _mesa_set_enable (enable.c:956)
==6988==by 0x4D138A6: _mesa_Enable (enable.c:971)
==6988==by 0x4769879: glEnable (glapitemp.h:1160)
==6988==by 0x4613A5F:
osgUtil::RenderStage::drawImplementation(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988==by
0x4607658: osgUtil::RenderBin::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988==by
0x46133BC: osgUtil::RenderStage::drawInner(osg::RenderInfo,
osgUtil::RenderLeaf*, bool) (in /usr/lib/libosgUtil.so) ==6988==by
0x4612E6C: osgUtil::RenderStage::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so) ==6988== Address
0x4AF585C is 4 bytes inside a block of size 8 free'd ==6988==at
0x402303F: free (vg_replace_malloc.c:233)
==6988==by 0x4BAF503: _mesa_free (imports.c:93)
==6988==by 0x4B2FF84: __driUtilUpdateDrawableInfo (dri_util.c:430)
==6988==by 0x4B2FD46: DoBindContext (dri_util.c:339)
==6988==by 0x4B2FF00: driBindContext (dri_util.c:383)
==6988==by 0x4735921: BindContextWrapper (glxext.c:1620)
==6988==by 0x4735A53: MakeContextCurrent (glxext.c:1674)
==6988==by 0x4735D7C: glXMakeCurrent (glxext.c:1796)
==6988==by 0x47D8BB3: Producer::RenderSurface::makeCurrent(bool) (in
/usr/lib/libProducer.so) ==6988==by 0x47DEEC6:
Producer::Camera::_frame(bool) (in /usr/lib/libProducer.so) ==6988==by
0x47DF75F: Producer::Camera::frame(bool) (in /usr/lib/libProducer.so)
==6988==by 0x47E2589: Producer::CameraGroup::_singleThreadedFrame() (in
/usr/lib/libProducer.so)
So I searched a bit, and I created the following patch, which touches
src/mesa/drivers/dri/common/dri_util.c, and more specifically
__driUtilUpdateDrawableInfo, calling _mesa_free for pdp-pClipRects and
pdp-pBackClipRects only inside if.
Does this look sane?
Valgrind does not warn anymore.
--
Papadakos Panagiotis
--- src/mesa/drivers/dri/common/dri_util.c 2007-02-02 19:30:24.0 +0200
+++ src/mesa/drivers/dri/common/dri_util_new.c 2007-02-02 19:34:39.0 +0200
@@ -426,13 +426,11 @@
return;
}
-if (pdp-pClipRects) {
- _mesa_free(pdp-pClipRects);
-}
-
-if (pdp-pBackClipRects) {
- _mesa_free(pdp-pBackClipRects);
-}
+/* Temporary hold pointers, so that we don't leak
+ * when (*dri_interface-getDrawableInfo) returns True
+ */
+drm_clip_rect_t * tempPClipRects = pdp-pClipRects;
+drm_clip_rect_t * tempPBackClipRects = pdp-pBackClipRects;
DRM_SPINUNLOCK(psp-pSAREA-drawable_lock, psp-drawLockID);
@@ -448,14 +446,29 @@
/* Error -- eg the window may have been destroyed. Keep going
* with no cliprects.
*/
-pdp-pStamp = pdp-lastStamp; /* prevent endless loop */
+
+ if (tempPClipRects) {
+ _mesa_free(tempPClipRects);
+ }
+
+ if (tempPBackClipRects) {
+ _mesa_free(tempPBackClipRects);
+ }
+
+ pdp-pStamp = pdp-lastStamp; /* prevent endless loop */
pdp-numClipRects = 0;
pdp-pClipRects = NULL;
pdp-numBackClipRects = 0;
pdp-pBackClipRects = NULL;
}
else
- pdp-pStamp = (psp-pSAREA-drawableTable[pdp-index].stamp);
+{
+ if(tempPClipRects)
+ _mesa_free(tempPClipRects);
+ if(tempPBackClipRects)
+ _mesa_free(tempPBackClipRects);
+pdp-pStamp = (psp-pSAREA-drawableTable[pdp-index].stamp);
+}
DRM_SPINLOCK(psp-pSAREA-drawable_lock, psp-drawLockID);
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm:radeon_cp_cmdbuf] *ERROR* radeon_cp_cmdbuf called without lock held problem
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 disabling AIGLX make a difference? I will try later, although I think that it only happens when I use valgrind to debug my app. (I am not sure about this, so I will have to test it!) -- Papadakos Panagiotis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Small memory leak in __glXReportDamage
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 = XFixesCreateRegion(dpy, xrects, num_rects); +free(xrects); XDamageAdd(dpy, drawable, region); XFixesDestroyRegion(dpy, region); #endif - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Invalid reads from intersect_rect in radeon_state.c of r300 driver. [PATCH included]
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 (radeon_state.c:131)
==6988==by 0x4B3CD04: radeonEnable (radeon_state.c:205)
==6988==by 0x4B4B1C1: r300Enable (r300_state.c:542)
==6988==by 0x4D13827: _mesa_set_enable (enable.c:956)
==6988==by 0x4D138A6: _mesa_Enable (enable.c:971)
==6988==by 0x4769879: glEnable (glapitemp.h:1160)
==6988==by 0x4613A5F:
osgUtil::RenderStage::drawImplementation(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so)
==6988==by 0x4607658: osgUtil::RenderBin::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so)
==6988==by 0x46133BC: osgUtil::RenderStage::drawInner(osg::RenderInfo,
osgUtil::RenderLeaf*, bool) (in /usr/lib/libosgUtil.so)
==6988==by 0x4612E6C: osgUtil::RenderStage::draw(osg::RenderInfo,
osgUtil::RenderLeaf*) (in /usr/lib/libosgUtil.so)
==6988== Address 0x4AF585C is 4 bytes inside a block of size 8 free'd
==6988==at 0x402303F: free (vg_replace_malloc.c:233)
==6988==by 0x4BAF503: _mesa_free (imports.c:93)
==6988==by 0x4B2FF84: __driUtilUpdateDrawableInfo (dri_util.c:430)
==6988==by 0x4B2FD46: DoBindContext (dri_util.c:339)
==6988==by 0x4B2FF00: driBindContext (dri_util.c:383)
==6988==by 0x4735921: BindContextWrapper (glxext.c:1620)
==6988==by 0x4735A53: MakeContextCurrent (glxext.c:1674)
==6988==by 0x4735D7C: glXMakeCurrent (glxext.c:1796)
==6988==by 0x47D8BB3: Producer::RenderSurface::makeCurrent(bool) (in
/usr/lib/libProducer.so)
==6988==by 0x47DEEC6: Producer::Camera::_frame(bool) (in
/usr/lib/libProducer.so)
==6988==by 0x47DF75F: Producer::Camera::frame(bool) (in
/usr/lib/libProducer.so)
==6988==by 0x47E2589: Producer::CameraGroup::_singleThreadedFrame() (in
/usr/lib/libProducer.so)
So I searched a bit, and I created the following patch, which touches
src/mesa/drivers/dri/common/dri_util.c,
and more specifically __driUtilUpdateDrawableInfo, calling _mesa_free for
pdp-pClipRects and pdp-pBackClipRects
only inside if.
Does this look sane?
Valgrind does not warn anymore.
--
Papadakos Panagiotis
--- src/mesa/drivers/dri/common/dri_util.c 2007-02-01 19:11:25.0 +0200
+++ src/mesa/drivers/dri/common/dri_util_new.c 2007-02-01 19:02:44.0 +0200
@@ -426,14 +426,6 @@
return;
}
-if (pdp-pClipRects) {
- _mesa_free(pdp-pClipRects);
-}
-
-if (pdp-pBackClipRects) {
- _mesa_free(pdp-pBackClipRects);
-}
-
DRM_SPINUNLOCK(psp-pSAREA-drawable_lock, psp-drawLockID);
if (!__driFindDrawable(psp-drawHash, pdp-draw) ||
@@ -448,7 +440,16 @@
/* Error -- eg the window may have been destroyed. Keep going
* with no cliprects.
*/
-pdp-pStamp = pdp-lastStamp; /* prevent endless loop */
+
+ if (pdp-pClipRects) {
+ _mesa_free(pdp-pClipRects);
+ }
+
+ if (pdp-pBackClipRects) {
+ _mesa_free(pdp-pBackClipRects);
+ }
+
+ pdp-pStamp = pdp-lastStamp; /* prevent endless loop */
pdp-numClipRects = 0;
pdp-pClipRects = NULL;
pdp-numBackClipRects = 0;
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
drm:radeon_cp_cmdbuf] *ERROR* radeon_cp_cmdbuf called without lock held problem
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 This is using r300 driver and aiglx. -- Papadakos Panagiotis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MGA and lockups during shutdown or switchmode
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after looking the related radeon patch
and now I can switch to the VTs or change the videomode without lockups.
But when I press Ctrl+Alt+Delete, sometimes my machine will lockup before
kdm starts a new Xserver or it will lockup right away after my monitor
has received the signal from the new Xserver.
If I kill the kdm process and then restart it everything will be ok. (At
least when I tried it)
So can anyone please help?
This is the patch:
--- mga_dri.c 2003-04-04 22:02:21.0 +0300
+++ mga_dri.c_new 2003-04-04 16:26:31.0 +0300
@@ -1359,6 +1359,7 @@
if (pMga-irq) {
drmCtlUninstHandler(pMga-drmFD);
pMga-irq = 0;
+ pMga-reg_ien = 0;
}
/* 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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA and lockups during shutdown or switchmode
Could this be a kernel problem?
I have been using 2.4.21-preX and 2.5.6X and all show for me the same
behaviour, with IO-APIC enabled or not.
It reminds me the problem I have with my Promise controller
which after a while if I have dma enabled it completely locks my machine.
What kernel are you 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 at 11:12, Panagiotis Papadakos wrote:
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after looking the related radeon patch
and now I can switch to the VTs or change the videomode without lockups.
But when I press Ctrl+Alt+Delete, sometimes my machine will lockup before
kdm starts a new Xserver or it will lockup right away after my monitor
has received the signal from the new Xserver.
If I kill the kdm process and then restart it everything will be ok. (At
least when I tried it)
So can anyone please help?
This is the patch:
--- mga_dri.c 2003-04-04 22:02:21.0 +0300
+++ mga_dri.c_new 2003-04-04 16:26:31.0 +0300
@@ -1359,6 +1359,7 @@
if (pMga-irq) {
drmCtlUninstHandler(pMga-drmFD);
pMga-irq = 0;
+ pMga-reg_ien = 0;
}
/* Cleanup DMA */
Can anyone explain to me what exactly this patch or the one for radeon
do? My guess/understanding is that this prevents interrupts from being
reenabled on server reset before the irq handler is readded.
That's my understanding as well.
But why does this cause a hang?
I'm not sure, maybe some kernels and/or machines don't like the
interrupt being enabled without the handler being installed. I couldn't
reproduce the problem on my Macs.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA and lockups during shutdown or switchmode
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 be a kernel problem?
I have been using 2.4.21-preX and 2.5.6X and all show for me the same
behaviour, with IO-APIC enabled or not.
It reminds me the problem I have with my Promise controller
which after a while if I have dma enabled it completely locks my machine.
What kernel are you 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 at 11:12, Panagiotis Papadakos wrote:
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after looking the related radeon patch
and now I can switch to the VTs or change the videomode without lockups.
But when I press Ctrl+Alt+Delete, sometimes my machine will lockup before
kdm starts a new Xserver or it will lockup right away after my monitor
has received the signal from the new Xserver.
If I kill the kdm process and then restart it everything will be ok. (At
least when I tried it)
So can anyone please help?
This is the patch:
--- mga_dri.c 2003-04-04 22:02:21.0 +0300
+++ mga_dri.c_new 2003-04-04 16:26:31.0 +0300
@@ -1359,6 +1359,7 @@
if (pMga-irq) {
drmCtlUninstHandler(pMga-drmFD);
pMga-irq = 0;
+ pMga-reg_ien = 0;
}
/* Cleanup DMA */
Can anyone explain to me what exactly this patch or the one for radeon
do? My guess/understanding is that this prevents interrupts from being
reenabled on server reset before the irq handler is readded.
That's my understanding as well.
But why does this cause a hang?
I'm not sure, maybe some kernels and/or machines don't like the
interrupt being enabled without the handler being installed. I couldn't
reproduce the problem on my Macs.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
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://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: G400 Compatibility Test Results
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 PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Matrox G400,latest Xfree CVS and Quake III problem
I am using the latest CVS from Xfree and the introduction of Quake III is not working.I have changed xc/xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c line 220 from __driMesaMessage(...) to __driUtilMessage(...) as Klaus Rose suggested and although I can play the game, the introduction renders the first 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
[Dri-devel] Re: Maybe fixed shared texture object problem
I am using a G400 dualheaded and that patch fixed my problem which was whenever I was using stereo,my screen locked up with messages like this. Now I really don't know anything else.Sometimes with complicated Virtual Worlds I get such messages with a message: End of memory blocks and I thought 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 8 Memory heap 0x8c27cd0: Offset:, Size:0004, U. ... This mainly happens when switching back and forth between different Gnome/Sawfish workspaces, meaning that the window manager (sawfish) is calling XUnmapWindow and XMapWindow on the top-level frames containing my GLX windows. The messages occur as a result of the XMapWindow calls. I am not sure the patch actually reduced the frequency of the messages or the texture garbling. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re:Maybe fixed shared texture object problem
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[heap][idx].prev, nr++)
{
+ /* If switching texturing schemes, then the SAREA might not
+ * have been properly cleared, so we need to reset the
+ * global texture LRU.
+ */
+ if ( idx * sz mmesa-mgaScreen-textureSize[heap] ) {
+ nr = MGA_NR_TEX_REGIONS;
+ break;
+ }
+
if (sarea-texList[heap][idx].age mmesa-texAge[heap]) {
-mgaTexturesGone(mmesa, heap, idx * sz, sz, 1);
+mgaTexturesGone(mmesa, heap, idx * sz, sz,
+sarea-texList[heap][idx].in_use);
}
}
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Maybe fixed shared texture object problem
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 nothing about DRI!So please test and check.The only problem
which I have now is that in some complex Virtual Environments there will
be messages in stderr about no free memory block,but without any
lockup as previous.The left view will work as expected but the right
one won't.Also without stereo there are no messages about no free memory
blocks.Does stereo needs so much memory,for example twice?Sorry for my
english..Thanks.
--- lib/GL/mesa/src/drv/mga/mgatexmem.c Tue Apr 10 19:07:51 2001
+++ lib/GL/mesa/src/drv/mga/mymgatexmem.c Sat Jan 26 04:22:10 2002
@@ -203,8 +203,6 @@
{
mgaTextureObjectPtr t, tmp;
-
-
foreach_s ( t, tmp, (mmesa-TexObjList[heap]) ) {
if (t-MemBlock-ofs = offset + size ||
@@ -218,12 +216,11 @@
* objects, however.
*/
if (t-bound)
-mgaSwapOutTexObj( mmesa, t );
+ mgaSwapOutTexObj( mmesa, t );
else
-mgaDestroyTexObj( mmesa, t );
+ mgaDestroyTexObj( mmesa, t );
}
-
-
+
if (in_use) {
t = (mgaTextureObjectPtr) CALLOC(sizeof(*t));
if (!t) return;
@@ -254,9 +251,19 @@
idx != MGA_NR_TEX_REGIONS nr MGA_NR_TEX_REGIONS ;
idx = sarea-texList[heap][idx].prev, nr++)
{
- if (sarea-texList[heap][idx].age mmesa-texAge[heap]) {
-mgaTexturesGone(mmesa, heap, idx * sz, sz, 1);
- }
+ /* If switching texturing schemes, then the SAREA might not
+ * have been properly cleared, so we need to reset the
+ * global texture LRU.
+ */
+ if ( idx * sz mmesa-mgaScreen-textureSize[heap] ) {
+ nr = MGA_NR_TEX_REGIONS;
+ break;
+ }
+
+ if (sarea-texList[heap][idx].age mmesa-texAge[heap]) {
+ mgaTexturesGone(mmesa, heap, idx * sz, sz,
+ sarea-texList[heap][idx].in_use);
+ }
}
if (nr == MGA_NR_TEX_REGIONS) {
@@ -271,8 +278,8 @@
mgaPrintLocalLRU( mmesa, heap );
}
- mmesa-texAge[heap] = sarea-texAge[heap];
mmesa-dirty |= MGA_UPLOAD_TEX0IMAGE | MGA_UPLOAD_TEX1IMAGE;
+ mmesa-texAge[heap] = sarea-texAge[heap];
}
/*
P.S.
Are all those if (0) with debugging messages in mga driver necessary?
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
