[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=39832





--- Comment #18 from Florian Mickler   2012-01-24 
23:15:56 ---
Is this still a problem in 3.2 / 3.3-rc1?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm/nouveau: fix move notify callback

[John Doe]

On vram buffer eviction the ttm_bo_move_accel_cleanup will the
mm_node field of struct ttm_mem_reg of new_mem placement to NULL.
As move notify call back is now call after ttm_bo_move_accel_cleanup
it was using NULL ptr for mm_node.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..3a9d978 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -814,13 +814,13 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)

list_for_each_entry(vma, >vma_list, head) {
if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
-   nouveau_vm_map(vma, new_mem->mm_node);
+   nouveau_vm_map(vma, bo->mem.mm_node);
} else
if (new_mem && new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem->
  num_pages << PAGE_SHIFT,
- new_mem->mm_node);
+ bo->mem.mm_node);
} else {
nouveau_vm_unmap(vma);
}
-- 
1.7.7.6


--SUOF0GtieIMvvwua--

[PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
 wrote:
> On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark  wrote:
>> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
  wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  
> wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>  wrote:
>>> #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
>>> extern void omapdrm_reserve_vram(void);
>>> #else
>>> static inline void omapdrm_reserve_vram(void) { }
>>> #endif
>>>
>>> Like how it's done with DSP stuff.
>>
>> right, but then you'd miss the omapdrm_reserve_vram() call at startup..
>
> Why?

 I guess drm.o is ending up in a module, but the code that calls that
 (in common.c) is not in a module, so you get an unresolved symbol at
 link
>>>
>>> Right... But that code can be moved as well. Just like with the bridge.
>>
>> Hmm, looks like for dsp bridge the memory reservation is moved to
>> devices.c. ?Although I'm not entirely sure how that is better... and
>> there is precedent for both approaches, ie. omapfb works like omapdrm,
>> and tidspbridge works as you suggest.
>>
>> seems a bit bikeshed'ish to me
>
> I will send a patch to fix omapfb, perhaps after that it will be a bit
> more clear how it should be done :) (if it gets accepted)

ok, but the thing I don't like is it splits up the drm device setup
from the omapdrm_reserve_vram() part (and similarly for omapfb),

but if this is the consensus of how it should be done, well.. when in
Rome, and all that

BR,
-R

> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: add support for streamout v4

[Alex Deucher]

On Tue, Jan 24, 2012 at 6:43 PM, Jerome Glisse  wrote:
> On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeucher at gmail.com wrote:
>> From: Marek Ol??k 
>>
>> v2: agd5f: add strmout CS checking, copy_dw register checking
>>
>> v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
>> will incorrectly patch the command stream for certain regs.
>>
>> v4: agd5f: add warning if safe reg check fails for copy_dw
>
> NAK
>
> You never check the stream out buffer size and you never check that
> the memory offset for dw copy is not after the bo end. See comment
> below. Sorry to not just do a v5 busy with ttm :(
>

I just sent out a new version which should address everything.  I went
ahead and implemented strict checking for 6xx/7xx.  I guess my main
concern with the strict checking on 6xx/7xx is that we will miss
corner cases have to revisit it later.  We've already had to revisit
the cb, db, and texture code in the cs checker to work around corner
cases and userspace problems and we will need to yet again for 2D
tiling.  I'm not sure the additional overhead and pain actually makes
things much safer considering how temperamental GPUs are in general.

Alex

> Beside this it looks ok.
>
> Cheers,
> Jerome
>
>>
>> Signed-off-by: Marek Ol??k 
>> Signed-off-by: Alex Deucher 
>> ---
>> ?drivers/gpu/drm/radeon/evergreen_cs.c ? ? | ?138 
>> +++--
>> ?drivers/gpu/drm/radeon/evergreend.h ? ? ? | ? ?9 ++
>> ?drivers/gpu/drm/radeon/r600_cs.c ? ? ? ? ?| ?137 
>> +++-
>> ?drivers/gpu/drm/radeon/r600d.h ? ? ? ? ? ?| ? ?6 ++
>> ?drivers/gpu/drm/radeon/radeon_drv.c ? ? ? | ? ?2 +-
>> ?drivers/gpu/drm/radeon/reg_srcs/cayman ? ?| ? 10 ++
>> ?drivers/gpu/drm/radeon/reg_srcs/evergreen | ? 10 ++
>> ?drivers/gpu/drm/radeon/reg_srcs/r600 ? ? ?| ? 10 ++
>> ?8 files changed, 309 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
>> b/drivers/gpu/drm/radeon/evergreen_cs.c
>> index f7442e6..8bc883a 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
>> @@ -60,6 +60,10 @@ struct evergreen_cs_track {
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? cb_shader_mask;
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? vgt_strmout_config;
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? vgt_strmout_buffer_config;
>> + ? ? struct radeon_bo ? ? ? ?*vgt_strmout_bo[4];
>> + ? ? u64 ? ? ? ? ? ? ? ? ? ? vgt_strmout_bo_mc[4];
>> + ? ? u32 ? ? ? ? ? ? ? ? ? ? vgt_strmout_bo_offset[4];
>> + ? ? u32 ? ? ? ? ? ? ? ? ? ? vgt_strmout_size[4];
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? db_depth_control;
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? db_depth_view;
>> ? ? ? u32 ? ? ? ? ? ? ? ? ? ? db_depth_size;
>> @@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
>> evergreen_cs_track *track)
>> ? ? ? track->db_s_write_offset = 0x;
>> ? ? ? track->db_s_read_bo = NULL;
>> ? ? ? track->db_s_write_bo = NULL;
>> +
>> + ? ? for (i = 0; i < 4; i++) {
>> + ? ? ? ? ? ? track->vgt_strmout_size[i] = 0;
>> + ? ? ? ? ? ? track->vgt_strmout_bo[i] = NULL;
>> + ? ? ? ? ? ? track->vgt_strmout_bo_offset[i] = 0x;
>> + ? ? ? ? ? ? track->vgt_strmout_bo_mc[i] = 0x;
>> + ? ? }
>> ?}
>>
>> ?static int evergreen_cs_track_check(struct radeon_cs_parser *p)
>> ?{
>> - ? ? struct evergreen_cs_track *track = p->track;
>> -
>> - ? ? /* we don't support stream out buffer yet */
>> - ? ? if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
>> - ? ? ? ? ? ? dev_warn(p->dev, "this kernel doesn't support SMX output 
>> buffer\n");
>> - ? ? ? ? ? ? return -EINVAL;
>> - ? ? }
>> -
>> ? ? ? /* XXX fill in */
>> ? ? ? return 0;
>> ?}
>> @@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct 
>> radeon_cs_parser *p, u32 reg, u32 idx)
>> ? ? ? case VGT_STRMOUT_BUFFER_CONFIG:
>> ? ? ? ? ? ? ? track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
>> ? ? ? ? ? ? ? break;
>> + ? ? case VGT_STRMOUT_BUFFER_BASE_0:
>> + ? ? case VGT_STRMOUT_BUFFER_BASE_1:
>> + ? ? case VGT_STRMOUT_BUFFER_BASE_2:
>> + ? ? case VGT_STRMOUT_BUFFER_BASE_3:
>> + ? ? ? ? ? ? r = evergreen_cs_packet_next_reloc(p, );
>> + ? ? ? ? ? ? if (r) {
>> + ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "bad SET_CONTEXT_REG "
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "0x%04X\n", reg);
>> + ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? ? ? ? }
>> + ? ? ? ? ? ? tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
>> + ? ? ? ? ? ? track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, 
>> idx) << 8;
>> + ? ? ? ? ? ? ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
>> + ? ? ? ? ? ? track->vgt_strmout_bo[tmp] = reloc->robj;
>> + ? ? ? ? ? ? track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
>> + ? ? ? ? ? ? break;
>> + ? ? case VGT_STRMOUT_BUFFER_SIZE_0:
>> + ? ? case VGT_STRMOUT_BUFFER_SIZE_1:
>> + ? ? case VGT_STRMOUT_BUFFER_SIZE_2:
>> + ? ? case VGT_STRMOUT_BUFFER_SIZE_3:
>> + ? ? ? ? ? ? tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
>> + ? ? ? ? ? ? track->vgt_strmout_size[tmp] = 

[PATCH] drm/radeon/kms: add support for streamout v5

[alexdeuc...@gmail.com]

From: Marek Ol??k 

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

v4: agd5f: add warning if safe reg check fails for copy_dw

v5: agd5f: add stricter checking for 6xx/7xx

Signed-off-by: Marek Ol??k 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  139 +--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  179 -
 drivers/gpu/drm/radeon/r600d.h|6 +
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 352 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..30d4a2e 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_offset = 0x;
track->db_s_read_bo = NULL;
track->db_s_write_bo = NULL;
+
+   for (i = 0; i < 4; i++) {
+   track->vgt_strmout_size[i] = 0;
+   track->vgt_strmout_bo[i] = NULL;
+   track->vgt_strmout_bo_offset[i] = 0x;
+   track->vgt_strmout_bo_mc[i] = 0x;
+   }
 }

 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p->track;
-
-   /* we don't support stream out buffer yet */
-   if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
-   dev_warn(p->dev, "this kernel doesn't support SMX output 
buffer\n");
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,38 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "bad SET_CONTEXT_REG "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
<< 8;
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+   track->vgt_strmout_bo[tmp] = reloc->robj;
+   track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   /* size in register is DWs, convert to bytes */
+   track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx) * 4;
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1049,32 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }

+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p->rdev->family >= CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg >> 7);
+   if 

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #4 from Simon Deziel   2012-01-24 
19:45:48 ---
Please disregard my comments (#2 and #3) as I'm looking at the wrong bug
obviously. My problem is apparently solvable by
https://lkml.org/lkml/2010/12/6/464 as outlined by Konrad Rzeszutek Wilk.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm/radeon: silence out possible lock dependency warning

[Alexandre Demers]

I suppose I can stop bisecting kernel about this possible lock and close
the bug then?

-- 
Alexandre Demers

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #3 from Simon Deziel   2012-01-24 
19:07:35 ---
I'm observing a similar issue with various kernels from 3.2 to 3.3rc1. This
only manifests when booting a Xen dom0 without "nomodeset" so I'm not sure
that's actually the same bug.

The console screen gets corrupted at login prompt but is OK before as boot
messages are displayed properly. The video card info is :

$ lspci -nnkx -s 01:00.0
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2
MX/MX 400] [10de:0110] (rev b2)
Subsystem: Micro-Star International Co., Ltd. MSI GeForce2 MX400 Pro32S
[MS-8817] [1462:8817]
Kernel modules: nouveau, nvidiafb, rivafb
00: de 10 10 01 07 00 b0 02 b2 00 00 03 00 20 00 00
10: 00 00 00 dc 08 00 00 d0 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 17 88
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01

The bug was initially opened on Launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917211).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #2 from Simon Deziel   2012-01-24 
19:03:24 ---
Created an attachment (id=72183)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72183)
dmesg without "nomodeset"

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm: Fix authentication kernel crash

[Thomas Hellstrom]

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Daniel Vetter 
Cc: stable at vger.kernel.org
---
Resent with Review-by and Cc added.

 drivers/gpu/drm/drm_auth.c |6 +-
 drivers/gpu/drm/drm_fops.c |5 +
 include/drm/drmP.h |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 3f46772..ba23790 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -101,7 +101,7 @@ static int drm_add_magic(struct drm_master *master, struct 
drm_file *priv,
  * Searches and unlinks the entry in drm_device::magiclist with the magic
  * number hash key, while holding the drm_device::struct_mutex lock.
  */
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
 {
struct drm_magic_entry *pt;
struct drm_hash_item *hash;
@@ -136,6 +136,8 @@ static int drm_remove_magic(struct drm_master *master, 
drm_magic_t magic)
  * If there is a magic number in drm_file::magic then use it, otherwise
  * searches an unique non-zero magic number and add it associating it with \p
  * file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
@@ -173,6 +175,8 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
  * \return zero if authentication successed, or a negative number otherwise.
  *
  * Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_authmagic(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c00cf15..6263b01 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -487,6 +487,11 @@ int drm_release(struct inode *inode, struct file *filp)
  (long)old_encode_dev(file_priv->minor->device),
  dev->open_count);

+   /* Release any auth tokens that might point to this file_priv,
+  (do that under the drm_global_mutex) */
+   if (file_priv->magic)
+   (void) drm_remove_magic(file_priv->master, file_priv->magic);
+
/* if the master has gone away we can't do anything with the lock */
if (file_priv->minor->master)
drm_master_release(dev, filp);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76caa67..92f0981 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1328,6 +1328,7 @@ extern int drm_getmagic(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 extern int drm_authmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);

 /* Cache management (drm_cache.c) */
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-- 
1.7.4.4

[PATCH] drm/radeon/kms: add support for streamout v4

[Jerome Glisse]

On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeucher at gmail.com wrote:
> From: Marek Ol??k 
> 
> v2: agd5f: add strmout CS checking, copy_dw register checking
> 
> v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
> will incorrectly patch the command stream for certain regs.
> 
> v4: agd5f: add warning if safe reg check fails for copy_dw

NAK

You never check the stream out buffer size and you never check that
the memory offset for dw copy is not after the bo end. See comment
below. Sorry to not just do a v5 busy with ttm :(

Beside this it looks ok.

Cheers,
Jerome

> 
> Signed-off-by: Marek Ol??k 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c |  138 
> +++--
>  drivers/gpu/drm/radeon/evergreend.h   |9 ++
>  drivers/gpu/drm/radeon/r600_cs.c  |  137 +++-
>  drivers/gpu/drm/radeon/r600d.h|6 ++
>  drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
>  drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
>  drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
>  drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
>  8 files changed, 309 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index f7442e6..8bc883a 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -60,6 +60,10 @@ struct evergreen_cs_track {
>   u32 cb_shader_mask;
>   u32 vgt_strmout_config;
>   u32 vgt_strmout_buffer_config;
> + struct radeon_bo*vgt_strmout_bo[4];
> + u64 vgt_strmout_bo_mc[4];
> + u32 vgt_strmout_bo_offset[4];
> + u32 vgt_strmout_size[4];
>   u32 db_depth_control;
>   u32 db_depth_view;
>   u32 db_depth_size;
> @@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
> evergreen_cs_track *track)
>   track->db_s_write_offset = 0x;
>   track->db_s_read_bo = NULL;
>   track->db_s_write_bo = NULL;
> +
> + for (i = 0; i < 4; i++) {
> + track->vgt_strmout_size[i] = 0;
> + track->vgt_strmout_bo[i] = NULL;
> + track->vgt_strmout_bo_offset[i] = 0x;
> + track->vgt_strmout_bo_mc[i] = 0x;
> + }
>  }
>  
>  static int evergreen_cs_track_check(struct radeon_cs_parser *p)
>  {
> - struct evergreen_cs_track *track = p->track;
> -
> - /* we don't support stream out buffer yet */
> - if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
> - dev_warn(p->dev, "this kernel doesn't support SMX output 
> buffer\n");
> - return -EINVAL;
> - }
> -
>   /* XXX fill in */
>   return 0;
>  }
> @@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct 
> radeon_cs_parser *p, u32 reg, u32 idx)
>   case VGT_STRMOUT_BUFFER_CONFIG:
>   track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
>   break;
> + case VGT_STRMOUT_BUFFER_BASE_0:
> + case VGT_STRMOUT_BUFFER_BASE_1:
> + case VGT_STRMOUT_BUFFER_BASE_2:
> + case VGT_STRMOUT_BUFFER_BASE_3:
> + r = evergreen_cs_packet_next_reloc(p, );
> + if (r) {
> + dev_warn(p->dev, "bad SET_CONTEXT_REG "
> + "0x%04X\n", reg);
> + return -EINVAL;
> + }
> + tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
> + track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
> << 8;
> + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + track->vgt_strmout_bo[tmp] = reloc->robj;
> + track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
> + break;
> + case VGT_STRMOUT_BUFFER_SIZE_0:
> + case VGT_STRMOUT_BUFFER_SIZE_1:
> + case VGT_STRMOUT_BUFFER_SIZE_2:
> + case VGT_STRMOUT_BUFFER_SIZE_3:
> + tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
> + track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);

r6xx path divide this value by 4 but you never check that :
track->vgt_strmout_bo_offset[tmp] + track->vgt_strmout_size <= bo.size

> + break;
> + case CP_COHER_BASE:
> + r = evergreen_cs_packet_next_reloc(p, );
> + if (r) {
> + dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
> + "0x%04X\n", reg);
> + return -EINVAL;
> + }
> + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
>   case CB_TARGET_MASK:
>   track->cb_target_mask = radeon_get_ib_value(p, idx);
>   break;
> @@ -1014,6 +1048,32 @@ static int 

[next] Null pointer dereference in nouveau_vm_map_sg

[Jerome Glisse]

On Sun, Jan 22, 2012 at 01:33:16PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 12:57:50AM +0100, Martin Nyhus wrote:
> > On Monday 16. January 2012 21:30:59 Jerome Glisse wrote:
> > > On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> > > > In some cases mem will be null in nouveau_vm_map_sg, resulting in a 
> > > > crash
> > > > at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough 
> > > > to
> > > > reproduce, so I can test patches if needed.
> > > How do you trigger this ?
> > 
> > Opening 10-15 high-res pictures in Firefox triggers it every time. Doing 
> > the 
> > same using Gimp does not, and neither does Firefox and lots of small images 
> > (eg. Google image search).
> 
> I seem to be able to trigger this by using both Chrome and Firefox and 
> seeing a YouTube video. I did at that time have a dual-head display, while
> in the past to reproduce this I had only one monitor and it took a bit of
> time before I hit it.

Can you please both test if attached patch fix it for you ?

Cheers,
Jerome

[PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>  wrote:
>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
>>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>>  wrote:
 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.
>>>
>>> right, but then you'd miss the omapdrm_reserve_vram() call at startup..
>>
>> Why?
>
> I guess drm.o is ending up in a module, but the code that calls that
> (in common.c) is not in a module, so you get an unresolved symbol at
> link

Right... But that code can be moved as well. Just like with the bridge.

-- 
Felipe Contreras

[PATCH] drm/radeon/kms: add support for streamout v4

[alexdeuc...@gmail.com]

From: Marek Ol??k 

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

v4: agd5f: add warning if safe reg check fails for copy_dw

Signed-off-by: Marek Ol??k 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  138 +++--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  137 +++-
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 309 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..8bc883a 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_offset = 0x;
track->db_s_read_bo = NULL;
track->db_s_write_bo = NULL;
+
+   for (i = 0; i < 4; i++) {
+   track->vgt_strmout_size[i] = 0;
+   track->vgt_strmout_bo[i] = NULL;
+   track->vgt_strmout_bo_offset[i] = 0x;
+   track->vgt_strmout_bo_mc[i] = 0x;
+   }
 }

 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p->track;
-
-   /* we don't support stream out buffer yet */
-   if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
-   dev_warn(p->dev, "this kernel doesn't support SMX output 
buffer\n");
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "bad SET_CONTEXT_REG "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
<< 8;
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+   track->vgt_strmout_bo[tmp] = reloc->robj;
+   track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1048,32 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }

+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p->rdev->family >= CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg >> 7);
+   if (i >= last_reg) {
+   dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, idx);
+  

[PATCH] drm/radeon/kms: add support for streamout v3

[alexdeuc...@gmail.com]

From: Marek Ol??k 

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

Signed-off-by: Marek Ol??k 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  137 +++--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  136 +++-
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 307 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..7bef5f8 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_offset = 0x;
track->db_s_read_bo = NULL;
track->db_s_write_bo = NULL;
+
+   for (i = 0; i < 4; i++) {
+   track->vgt_strmout_size[i] = 0;
+   track->vgt_strmout_bo[i] = NULL;
+   track->vgt_strmout_bo_offset[i] = 0x;
+   track->vgt_strmout_bo_mc[i] = 0x;
+   }
 }

 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p->track;
-
-   /* we don't support stream out buffer yet */
-   if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
-   dev_warn(p->dev, "this kernel doesn't support SMX output 
buffer\n");
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "bad SET_CONTEXT_REG "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
<< 8;
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+   track->vgt_strmout_bo[tmp] = reloc->robj;
+   track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1048,31 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }

+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p->rdev->family >= CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg >> 7);
+   if (i >= last_reg) {
+   dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, idx);
+   return false;
+   }
+   m = 1 << ((reg >> 2) & 

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Michel D?nzer  2012-01-24 09:07:22 
PST ---
Fixed in commit 7219af5ec184d4f92682e75f3d992ae048005d6a ('gallium/postprocess:
Proper reference counting of pp_jimenezmlaa depth buffer.')

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44919] Wayland clients segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

--- Comment #10 from Scott Moreau  2012-01-24 07:56:34 PST 
---
(In reply to comment #9)
> Possible fix:
> http://lists.freedesktop.org/archives/mesa-dev/2012-January/018029.html

I tested this patch and it solves the issue with weston clients here on r300g.
Thanks Alex.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

new GPU hang [was: g33: GPU hangs]

[Jiri Slaby]

On 01/18/2012 12:43 PM, Daniel Vetter wrote:
>>> From 2b76187d2f5fc2352e391914b1828f91f93bb356 Mon Sep 17 00:00:00 2001
>>> From: Chris Wilson 
>>> Date: Tue, 29 Nov 2011 15:12:16 +
>>> Subject: [PATCH] drm/i915: Only clear the GPU domains upon a successful
>>>  finish
>>
>> Hi, do you plan to push this patch upstream? Or am I supposed to not use
>> it anymore?
> 
> It's on track to get merged to drm-intel-next. I'll probably pick it up in a 
> week
> or so.

OK, thanks.

Even though I use the patch, today another hang occurred:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting
910502 at 910475, next 910519)
[drm:i915_reset] *ERROR* Failed to reset chip.

I was cruising through a map at openstreetmaps.org. This was
3.2.0-next-20120118_64+. FWIW I updated to 3.3.0-rc1-next-20120124_64+
right now.

Is it related to the bug I reported at:
https://bugs.freedesktop.org/show_bug.cgi?id=43427
?

dmesg:
http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state.dmesg

error_state:
http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state

thanks,
-- 
js

[PATCH] drm: Fix authentication kernel crash

[Daniel Vetter]

On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
> If the master tries to authenticate a client using drm_authmagic and
> that client has already closed its drm file descriptor,
> either wilfully or because it was terminated, the
> call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
> and corrupt it.
> 
> Typically this results in a hard system hang.
> 
> This patch fixes that problem by removing any authentication tokens
> (struct drm_magic_entry) open for a file descriptor when that file
> descriptor is closed.
> 
> Signed-off-by: Thomas Hellstrom 

Ok, I've wandered around a bit in this and noticed that the locking is the
usual convoluted disaster. We seem to randomly grab dev->struct_mutex in
the auth and master ioctl, but all the real protect seems to be due to
taking the global mutex in all relevant paths.

I guess I can't volunteer you to clean this up ;-)

Otherwise I couldn't poke a hole into this, so
Reviewed-by: Daniel Vetter 
>  
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 40034] E-350 misprocesses shader

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40034

--- Comment #10 from Lauri Kasanen  2012-01-24 
07:11:39 PST ---
I can test on the weekend.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

--- Comment #5 from Fabio Pedretti  2012-01-24 06:18:21 
PST ---
(In reply to comment #4)
> Is this still an issue with the latest mesa git?

Yes

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44919] Wayland clients segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

--- Comment #9 from Alex Deucher  2012-01-24 06:15:48 PST 
---
Possible fix:
http://lists.freedesktop.org/archives/mesa-dev/2012-January/018029.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

--- Comment #4 from Alex Deucher  2012-01-24 05:58:55 PST 
---
Is this still an issue with the latest mesa git?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 40034] E-350 misprocesses shader

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40034

--- Comment #9 from Alex Deucher  2012-01-24 05:58:00 PST 
---
Is this still an issue with latest git?  This commit looks relevant:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d89c96c75dbb9c003e4643942f2cce8d6cd4995b

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: silence out possible lock dependency warning

[j.gli...@gmail.com]

From: Jerome Glisse 

Silence out the lock dependency warning by moving bo allocation out
of ib mutex protected section. Might lead to useless temporary
allocation but it's not harmful as such things only happen at
initialization.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_ring.c |   19 +++
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index e8bc709..1cb4b94 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -204,22 +204,25 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct 
radeon_ib *ib)

 int radeon_ib_pool_init(struct radeon_device *rdev)
 {
+   struct radeon_sa_manager tmp;
int i, r;

-   mutex_lock(>ib_pool.mutex);
-   if (rdev->ib_pool.ready) {
-   mutex_unlock(>ib_pool.mutex);
-   return 0;
-   }
-
-   r = radeon_sa_bo_manager_init(rdev, >ib_pool.sa_manager,
+   r = radeon_sa_bo_manager_init(rdev, ,
  RADEON_IB_POOL_SIZE*64*1024,
  RADEON_GEM_DOMAIN_GTT);
if (r) {
-   mutex_unlock(>ib_pool.mutex);
return r;
}

+   mutex_lock(>ib_pool.mutex);
+   if (rdev->ib_pool.ready) {
+   mutex_unlock(>ib_pool.mutex);
+   radeon_sa_bo_manager_fini(rdev, );
+   return 0;
+   }
+
+   rdev->ib_pool.sa_manager = tmp;
+   INIT_LIST_HEAD(>ib_pool.sa_manager.sa_bo);
for (i = 0; i < RADEON_IB_POOL_SIZE; i++) {
rdev->ib_pool.ibs[i].fence = NULL;
rdev->ib_pool.ibs[i].idx = i;
-- 
1.7.7.1

[PATCH] drm/radeon/kms: add support for streamout v2

[alexdeuc...@gmail.com]

From: Marek Ol??k 

v2: agd5f: add strmout CS checking, copy_dw register checking

Signed-off-by: Marek Ol??k 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  114 +--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  123 -
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 +++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 +++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 +++
 8 files changed, 271 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..1e23c3c 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_offset = 0x;
track->db_s_read_bo = NULL;
track->db_s_write_bo = NULL;
+
+   for (i = 0; i < 4; i++) {
+   track->vgt_strmout_size[i] = 0;
+   track->vgt_strmout_bo[i] = NULL;
+   track->vgt_strmout_bo_offset[i] = 0x;
+   track->vgt_strmout_bo_mc[i] = 0x;
+   }
 }

 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p->track;
-
-   /* we don't support stream out buffer yet */
-   if (track->vgt_strmout_config || track->vgt_strmout_buffer_config) {
-   dev_warn(p->dev, "this kernel doesn't support SMX output 
buffer\n");
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track->vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "bad SET_CONTEXT_REG "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track->vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
<< 8;
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+   track->vgt_strmout_bo[tmp] = reloc->robj;
+   track->vgt_strmout_bo_mc[tmp] = reloc->lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track->vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   dev_warn(p->dev, "missing reloc for CP_COHER_BASE "
+   "0x%04X\n", reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1451,6 +1485,70 @@ static int evergreen_packet3_check(struct 
radeon_cs_parser *p,
return -EINVAL;
}
break;
+   case PACKET3_STRMOUT_BUFFER_UPDATE:
+   if (pkt->count != 4) {
+   DRM_ERROR("bad STRMOUT_BUFFER_UPDATE (invalid 
count)\n");
+   return -EINVAL;
+   }
+   /* Updating memory at DST_ADDRESS. */
+   if (idx_value & 0x1) {
+   r = evergreen_cs_packet_next_reloc(p, );
+   if (r) {
+   DRM_ERROR("bad STRMOUT_BUFFER_UPDATE (missing 
reloc 1)\n");
+   return -EINVAL;
+   

Looking for libsegfault

[Rafał Miłecki]

Hey,

I want to do some RE-ing and I'm looking for libsegfault to trace Xorg
driver ops. Unfortunately I can't find libsegfault at
http://people.freedesktop.org/~glisse/ anymore.

Can someone share this, please?

-- 
Rafa?

[PATCH] drm: Fix authentication kernel crash

[Thomas Hellstrom]

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.

Signed-off-by: Thomas Hellstrom 
---
Please review. This should also go into stable kernels.

 drivers/gpu/drm/drm_auth.c |6 +-
 drivers/gpu/drm/drm_fops.c |5 +
 include/drm/drmP.h |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 3f46772..ba23790 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -101,7 +101,7 @@ static int drm_add_magic(struct drm_master *master, struct 
drm_file *priv,
  * Searches and unlinks the entry in drm_device::magiclist with the magic
  * number hash key, while holding the drm_device::struct_mutex lock.
  */
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
 {
struct drm_magic_entry *pt;
struct drm_hash_item *hash;
@@ -136,6 +136,8 @@ static int drm_remove_magic(struct drm_master *master, 
drm_magic_t magic)
  * If there is a magic number in drm_file::magic then use it, otherwise
  * searches an unique non-zero magic number and add it associating it with \p
  * file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
@@ -173,6 +175,8 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
  * \return zero if authentication successed, or a negative number otherwise.
  *
  * Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_authmagic(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c00cf15..6263b01 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -487,6 +487,11 @@ int drm_release(struct inode *inode, struct file *filp)
  (long)old_encode_dev(file_priv->minor->device),
  dev->open_count);

+   /* Release any auth tokens that might point to this file_priv,
+  (do that under the drm_global_mutex) */
+   if (file_priv->magic)
+   (void) drm_remove_magic(file_priv->master, file_priv->magic);
+
/* if the master has gone away we can't do anything with the lock */
if (file_priv->minor->master)
drm_master_release(dev, filp);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76caa67..92f0981 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1328,6 +1328,7 @@ extern int drm_getmagic(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 extern int drm_authmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);

 /* Cache management (drm_cache.c) */
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-- 
1.7.4.4

Looking for libsegfault

[Jerome Glisse]

2012/1/24 Rafa? Mi?ecki :
> Hey,
>
> I want to do some RE-ing and I'm looking for libsegfault to trace Xorg
> driver ops. Unfortunately I can't find libsegfault at
> http://people.freedesktop.org/~glisse/ anymore.
>
> Can someone share this, please?
>
> --
> Rafa?

You better of using valgrind. I am not even sure the trick used in
libsegfault work anymore also it was only for x86 kernel.

Cheers,
Jerome

[PATCH] drm/nouveau: fix ttm move notify callback

[Konrad Rzeszutek Wilk]

On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
> On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Still having difficulty to reproduce can you reproduce with the attached
> > > > printk debuging patch and provide the log (only few printk preceding the
> > > > oops or segfault are interesting).
> > > 
> > > http://darnok.org/vga/move_notify-v212.log
> > > 
> > 
> > Looks like nouveau doesn't like move notify being call on driver
> > shutdown or when somethings om nv50 is down. Ben i think you will
> > be better at finding a fix for that than me.
> I'm also not able to reproduce this issue on a NV98 (so, i'd expect
> every nv50+ chipset to behave the same) chipset with the current code in
> Dave's drm-core-next tree..

There looks to be a bug about this openned when folks where using firefox
and seeing large pictures or scrolling through a large web-page.

Any thoughts or things I could try out to narrow this down?

[PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
  wrote:
> #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
> extern void omapdrm_reserve_vram(void);
> #else
> static inline void omapdrm_reserve_vram(void) { }
> #endif
>
> Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..
>>>
>>> Why?
>>
>> I guess drm.o is ending up in a module, but the code that calls that
>> (in common.c) is not in a module, so you get an unresolved symbol at
>> link
>
> Right... But that code can be moved as well. Just like with the bridge.

Hmm, looks like for dsp bridge the memory reservation is moved to
devices.c.  Although I'm not entirely sure how that is better... and
there is precedent for both approaches, ie. omapfb works like omapdrm,
and tidspbridge works as you suggest.

seems a bit bikeshed'ish to me

BR,
-R

> --
> Felipe Contreras

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43835

--- Comment #32 from Camale?n  2012-01-24 01:16:03 PST 
---
(In reply to comment #31)
> bugzilla-daemon at freedesktop.org wrote:
> 
> > The user reported that system crashed after a while.
> 
> Interesting --- so it sounds like there is a random element to this,
> too.  Can we have a log of the crash, please?

I have asked the user for it. He will have to wait until the system locks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: Fix authentication kernel crash

[Greg KH]

On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
> If the master tries to authenticate a client using drm_authmagic and
> that client has already closed its drm file descriptor,
> either wilfully or because it was terminated, the
> call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
> and corrupt it.
> 
> Typically this results in a hard system hang.
> 
> This patch fixes that problem by removing any authentication tokens
> (struct drm_magic_entry) open for a file descriptor when that file
> descriptor is closed.
> 
> Signed-off-by: Thomas Hellstrom 
> ---
> Please review. This should also go into stable kernels.



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

[PATCH 1/2] drm/radeon: fix invalid memory access in radeon_atrm_get_bios()

[Alex Deucher]

On Sun, Jan 22, 2012 at 9:43 AM, Igor Murzov
 wrote:
> From 77c912ea1eca50a93a34d5be69f9dc96a8bef0d8 Mon Sep 17 00:00:00 2001
> From: Igor Murzov 
> Date: Sun, 22 Jan 2012 19:02:27 +0400
> Subject: [PATCH 1/2] drm/radeon: fix invalid memory access in 
> radeon_atrm_get_bios()
>
> At a boot time I observed following bug:
>
> ?BUG: unable to handle kernel paging request at 8800a4244000
> ?IP: [] memcpy+0xb/0x120
> ?PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 8000a4244160
> ?Oops:  [#1] SMP DEBUG_PAGEALLOC
> ?CPU 0
> ?Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 
> radeon(+)
> ?mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
> ?sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys 
> snd_hda_codec_hdmi
> ?joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
> ?snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
> ?i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw 
> snd_page_alloc
> ?loop btrfs
>
> ?Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046 ? ? ? ? ? ? 
> ? ? ? ? ? ? ? /AMD CRB
> ?RIP: 0010:[] ?[] memcpy+0xb/0x120
> ?RSP: 0018:8800aa72db00 ?EFLAGS: 00010246
> ?RAX: 8800a415 RBX: 1000 RCX: 0087
> ?RDX:  RSI: 8800a4244000 RDI: 8800a4150bc8
> ?RBP: 8800aa72db78 R08: 0010 R09: 8174bbec
> ?R10: 812ee010 R11: 0001 R12: 1000
> ?R13: 0001 R14: 8800a414 R15: 8800aaba1800
> ?FS: ?7ff9a3bd4720() GS:8800afa0() knlGS:
> ?CS: ?0010 DS:  ES:  CR0: 8005003b
> ?CR2: 8800a4244000 CR3: a9c18000 CR4: 06f0
> ?DR0:  DR1:  DR2: 
> ?DR3:  DR6: 0ff0 DR7: 0400
> ?Process modprobe (pid: 1008, threadinfo 8800aa72c000, task 
> 8800aa0e4000)
> ?Stack:
> ?a04e7c7b 0001 0001 8800aa72db28
> ?0001 1000 8113cbef 0020
> ?8800a4243420 8802 8800aa72db08 8800a9d42000
> ?Call Trace:
> ?[] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
> ?[] ? kmalloc_order_trace+0x3f/0xb0
> ?[] radeon_get_bios+0x68/0x2f0 [radeon]
> ?[] rv770_init+0x40/0x280 [radeon]
> ?[] radeon_device_init+0x560/0x600 [radeon]
> ?[] radeon_driver_load_kms+0xaf/0x170 [radeon]
> ?[] drm_get_pci_dev+0x18e/0x2c0 [drm]
> ?[] radeon_pci_probe+0xad/0xb5 [radeon]
> ?[] local_pci_probe+0x5f/0xd0
> ?[] pci_device_probe+0x88/0xb0
> ?[] ? driver_sysfs_add+0x7a/0xb0
> ?[] really_probe+0x68/0x180
> ?[] driver_probe_device+0x45/0x70
> ?[] __driver_attach+0xa3/0xb0
> ?[] ? driver_probe_device+0x70/0x70
> ?[] bus_for_each_dev+0x5e/0x90
> ?[] driver_attach+0x1e/0x20
> ?[] bus_add_driver+0xc8/0x280
> ?[] driver_register+0x76/0x140
> ?[] __pci_register_driver+0x66/0xe0
> ?[] drm_pci_init+0x111/0x120 [drm]
> ?[] ? vga_switcheroo_register_handler+0x3a/0x60
> ?[] ? 0xa0228fff
> ?[] radeon_init+0xec/0xee [radeon]
> ?[] do_one_initcall+0x42/0x180
> ?[] sys_init_module+0x92/0x1e0
> ?[] system_call_fastpath+0x16/0x1b
> ?Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
> ?e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07  48
> ?a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
> ?RIP ?[] memcpy+0xb/0x120
> ?RSP 
> ?CR2: 8800a4244000
> ?---[ end trace fcffa1599cf56382 ]---
>
> Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
> on my system it can return 2048 bytes chunk, so pass the length of
> retrieved chunk to memcpy(), not the length of the recieving buffer.
>
> Signed-off-by: Igor Murzov 

Both patches are:
Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon_atpx_handler.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index 9d95792..c666a5b 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -58,7 +58,7 @@ static int radeon_atrm_call(acpi_handle atrm_handle, 
> uint8_t *bios,
> ? ? ? ?}
>
> ? ? ? ?obj = (union acpi_object *)buffer.pointer;
> - ? ? ? memcpy(bios+offset, obj->buffer.pointer, len);
> + ? ? ? memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
> ? ? ? ?kfree(buffer.pointer);
> ? ? ? ?return len;
> ?}
> --
> 1.7.5.1
>

[3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec

[Torsten Kaiser]

On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
 wrote:
> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse  wrote:
>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
>>> After updating to kernel 3.3-rc1 I have experienced a lockup of my GPU.
>>> I left my KDE desktop running until the screensaver turned off the
>>> monitors. But on key presses it would not turn back on. Ctrl+Alt+F1 to
>>> switch to another virtual console also did not work.
>>> Alt+SysRq magic still worked, so I was able to force the syslog to
>>> disk and restart the system.
>>>
>>
>> Can you test if attached patch help your case ?
>
> Patch is installed, but I can't reproduce the hang on demand.
> It did happen a second time yesterday while letting the screensaver
> kick in, but only at around the third or fourth try. Just using "xset
> dpms force standby/suspend/off" did not trigger it.

I think the patch did what it was intended to do, but it did not really help.
While the GPU reset did seem to work, X still got stuck and was not
able to turn the monitors back on.

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43835

--- Comment #31 from Jonathan Nieder  2012-01-24 
00:00:35 PST ---
bugzilla-daemon at freedesktop.org wrote:

> The user reported that system crashed after a while.

Interesting --- so it sounds like there is a random element to this,
too.  Can we have a log of the crash, please?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43835

--- Comment #30 from Camale?n  2012-01-23 23:58:35 PST 
---
(In reply to comment #29)

> I neither see a kernel oops at the "syslog". I just have asked the user if the
> system crashed this time again.

The user reported that system crashed after a while.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

GPU lockup CP stall for more than 1msec
Jan 23 23:53:54 thoregon kernel: [17121.080137] GPU lockup (waiting
for 0x002080B7 last fence id 0x002080B6)
Jan 23 23:53:54 thoregon kernel: [17121.096334] radeon :07:00.0:
GPU softreset
Jan 23 23:53:54 thoregon kernel: [17121.096341] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 23 23:53:54 thoregon kernel: [17121.096346] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.096351] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.096362] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 23 23:53:54 thoregon kernel: [17121.111386] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 23 23:53:54 thoregon kernel: [17121.127378] radeon :07:00.0:
R_008010_GRBM_STATUS=0x3028
Jan 23 23:53:54 thoregon kernel: [17121.127384] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.127390] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.128393] radeon :07:00.0:
GPU reset succeed
Jan 23 23:53:54 thoregon kernel: [17121.10] [drm] PCIE GART of
512M enabled (table at 0x0004).
Jan 23 23:53:54 thoregon kernel: [17121.133364] radeon :07:00.0: WB enabled
Jan 23 23:53:54 thoregon kernel: [17121.133370] [drm] fence driver on
ring 0 use gpu addr 0x2c00 and cpu addr 0x8803286e5c00
Jan 23 23:53:54 thoregon kernel: [17121.179627] [drm] ring test on 0
succeeded in 1 usecs
Jan 23 23:53:54 thoregon kernel: [17121.179653] [drm] ib test on ring
0 succeeded in 1 usecs

There where no messages about X getting stuck ("blocked for more than
120 seconds"), but after trying to access the system and failing
SysRq+W reported this:
Jan 24 08:08:20 thoregon kernel: [46786.741180] SysRq : Show Blocked State
Jan 24 08:08:20 thoregon kernel: [46786.741190]   task
   PC stack   pid father
Jan 24 08:08:20 thoregon kernel: [46786.741270] X   D
880337d50a00 0  3047   3026 0x0044
Jan 24 08:08:20 thoregon kernel: [46786.741281]  880327eacac0
0086 880327d52e00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741292]  88031be9bfd8
00010a00 88031be9a000 88031be9bfd8
Jan 24 08:08:20 thoregon kernel: [46786.741301]  00010a00
880327eacac0 00010a00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741310] Call Trace:
Jan 24 08:08:20 thoregon kernel: [46786.741326]  []
? schedule_timeout+0x157/0x220
Jan 24 08:08:20 thoregon kernel: [46786.741336]  []
? run_timer_softirq+0x240/0x240
Jan 24 08:08:20 thoregon kernel: [46786.741346]  []
? radeon_fence_wait+0x239/0x3b0
Jan 24 08:08:20 thoregon kernel: [46786.741356]  []
? wake_up_bit+0x40/0x40
Jan 24 08:08:20 thoregon kernel: [46786.741364]  []
? radeon_ib_get+0x257/0x2e0
Jan 24 08:08:20 thoregon kernel: [46786.741372]  []
? radeon_cs_ioctl+0x27a/0x4d0
Jan 24 08:08:20 thoregon kernel: [46786.741381]  []
? drm_ioctl+0x3e4/0x490
Jan 24 08:08:20 thoregon kernel: [46786.741389]  []
? radeon_cs_finish_pages+0xa0/0xa0
Jan 24 08:08:20 thoregon kernel: [46786.741398]  []
? do_page_fault+0x199/0x420
Jan 24 08:08:20 thoregon kernel: [46786.741406]  []
? mmap_region+0x1dc/0x570
Jan 24 08:08:20 thoregon kernel: [46786.741414]  []
? do_vfs_ioctl+0x96/0x4e0
Jan 24 08:08:20 thoregon kernel: [46786.741422]  []
? sys_ioctl+0x49/0x90
Jan 24 08:08:20 thoregon kernel: [46786.741430]  []
? system_call_fastpath+0x16/0x1b

I did search my logs for more GPU lockups after noting that this also
happened with 3.2.
The first lockup in my logs occurred on Nov 4 under 3.1. But until
3.3-rc1 X always was able to resume normal operations.

My best guess for the cause of the GPU lockups seems to be the upgrade
from xf86-video-ati-6.14.2 to 6.14.3, but 3.3-rc1 seems to have an
independent bug that prevents X to recover from a GPU lockup/reset.

>> Of course it would be best if we did not lockup in the first place.
>
> Not sure if this is important: I also upgraded to mesa 8.0-rc1 before
> the first hang, but after switching back to 3.2 but still using mesa
> 8.0 I did not have any problems.
> Except the KDE desktop effects there should not have been any OpenGL
> programs running.
> The screen saver itself is just turning the screens off via the KDE
> power profile.
>
> I will report again, when I succeeded in triggering the GPU lockup again...
>
> Torsten

[Bug 44919] Wayland clients segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

Scott Moreau  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r300|Mesa core

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Alexandre Demers  
2012-01-23 22:20:21 PST ---
One of the latest commits fixed the issue. Many commits were related to r600g,
some were specific to cayman, one of them must have fixed it. Closing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 44919] Wayland clients segfault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

--- Comment #8 from Ran Benita  2012-01-23 17:21:56 PST ---
Sorry, here are some more details.

ran at ran:~$ uname -sr
Linux 3.2.1-1-ARCH
ran at ran:~$ lspci | grep nVi
01:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT]
(rev a1)
ran at ran:~$ glxinfo | grep nouveau -A3
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV94
OpenGL version string: 2.1 Mesa 8.0-devel (git-c25e5300)
OpenGL shading language version string: 1.20

Mesa config:
--with-dri-drivers= --with-gallium-drivers=nouveau
--with-egl-platforms=drm,x11 --enable-gallium-egl
--enable-shared-dricore --enable-shared-glapi --enable-egl
--enable-gles2 --enable-glx-tls --enable-xcb --enable-texture-float

And the backtrace:
Core was generated by `./test_terminal'.
Program terminated with signal 11, Segmentation fault.
#0  st_framebuffer_validate (stfb=0x7f89888e1e60, st=) at
state_tracker/st_manager.c:186
186   int32_t new_stamp = p_atomic_read(>iface->stamp);
(gdb) bt
#0  st_framebuffer_validate (stfb=0x7f89888e1e60, st=) at
state_tracker/st_manager.c:186
#1  0x7f8987a5ca28 in st_api_make_current (stapi=,
stctxi=0x1588910, stdrawi=, streadi=)
at state_tracker/st_manager.c:731
#2  0x7f89879b47cf in driBindContext (pcp=, pdp=, prp=)
at ../../../../src/mesa/drivers/dri/common/dri_util.c:330
#3  0x7f898c1aba60 in dri2_make_current (drv=0x14a4a70, disp=0x149eb20,
dsurf=0x0, rsurf=0x0, ctx=0x14a5690) at egl_dri2.c:818
#4  0x7f898c1a4d39 in eglMakeCurrent (dpy=0x149eb20, draw=0x0, read=0x0,
ctx=0x14a5690) at eglapi.c:502
#5  0x004065b2 in context_use (ctx=0x149c700) at
src/output_context.c:589
#6  0x00405206 in compositor_use (comp=0x146cf50) at src/output.c:936
#7  0x004039e0 in setup_app (app=0x7fff094f6440) at
tests/test_terminal.c:224
#8  0x00403b98 in main (argc=1, argv=0x7fff094f6588) at
tests/test_terminal.c:273

This only happens if eglMakeCurrent is called twice, which is the case in my
program and in wayland also (e.g. there's a call to eglMakeCurrent followed by
a call to cairo_egl_device_create, which also calls eglMakeCurrent).

Since we use the surfaceless extension the first call to
st_manager.c:st_api_make_current uses an incomplete buffer as a dummy (I
think?), so then:

(gdb) print stfb ==  
$11 = 1

In the next call the following check at st_manager.c:730 :
if (stdraw && stread) {
passes but:

(gdb) print stfb->iface
$28 = (struct st_framebuffer_iface *) 0x0

So there's a null dereference. I'm not familiar with mesa so I can't help with
a (correct) patch.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43835

--- Comment #31 from Jonathan Nieder jrnie...@gmail.com 2012-01-24 00:00:35 
PST ---
bugzilla-dae...@freedesktop.org wrote:

 The user reported that system crashed after a while.

Interesting --- so it sounds like there is a random element to this,
too.  Can we have a log of the crash, please?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43835

--- Comment #32 from Camaleón noela...@gmail.com 2012-01-24 01:16:03 PST ---
(In reply to comment #31)
 bugzilla-dae...@freedesktop.org wrote:
 
  The user reported that system crashed after a while.
 
 Interesting --- so it sounds like there is a random element to this,
 too.  Can we have a log of the crash, please?

I have asked the user for it. He will have to wait until the system locks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix authentication kernel crash

[Thomas Hellstrom]

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
Please review. This should also go into stable kernels.

 drivers/gpu/drm/drm_auth.c |6 +-
 drivers/gpu/drm/drm_fops.c |5 +
 include/drm/drmP.h |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 3f46772..ba23790 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -101,7 +101,7 @@ static int drm_add_magic(struct drm_master *master, struct 
drm_file *priv,
  * Searches and unlinks the entry in drm_device::magiclist with the magic
  * number hash key, while holding the drm_device::struct_mutex lock.
  */
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
 {
struct drm_magic_entry *pt;
struct drm_hash_item *hash;
@@ -136,6 +136,8 @@ static int drm_remove_magic(struct drm_master *master, 
drm_magic_t magic)
  * If there is a magic number in drm_file::magic then use it, otherwise
  * searches an unique non-zero magic number and add it associating it with \p
  * file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
@@ -173,6 +175,8 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
  * \return zero if authentication successed, or a negative number otherwise.
  *
  * Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_authmagic(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c00cf15..6263b01 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -487,6 +487,11 @@ int drm_release(struct inode *inode, struct file *filp)
  (long)old_encode_dev(file_priv-minor-device),
  dev-open_count);
 
+   /* Release any auth tokens that might point to this file_priv,
+  (do that under the drm_global_mutex) */
+   if (file_priv-magic)
+   (void) drm_remove_magic(file_priv-master, file_priv-magic);
+
/* if the master has gone away we can't do anything with the lock */
if (file_priv-minor-master)
drm_master_release(dev, filp);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76caa67..92f0981 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1328,6 +1328,7 @@ extern int drm_getmagic(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 extern int drm_authmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);
 
 /* Cache management (drm_cache.c) */
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Looking for libsegfault

[Rafał Miłecki]

Hey,

I want to do some RE-ing and I'm looking for libsegfault to trace Xorg
driver ops. Unfortunately I can't find libsegfault at
http://people.freedesktop.org/~glisse/ anymore.

Can someone share this, please?

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40034] E-350 misprocesses shader

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40034

--- Comment #9 from Alex Deucher ag...@yahoo.com 2012-01-24 05:58:00 PST ---
Is this still an issue with latest git?  This commit looks relevant:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d89c96c75dbb9c003e4643942f2cce8d6cd4995b

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

--- Comment #4 from Alex Deucher ag...@yahoo.com 2012-01-24 05:58:55 PST ---
Is this still an issue with the latest mesa git?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/radeon: fix invalid memory access in radeon_atrm_get_bios()

[Alex Deucher]

On Sun, Jan 22, 2012 at 9:43 AM, Igor Murzov
intergalactic.anonym...@gmail.com wrote:
 From 77c912ea1eca50a93a34d5be69f9dc96a8bef0d8 Mon Sep 17 00:00:00 2001
 From: Igor Murzov e-m...@date.by
 Date: Sun, 22 Jan 2012 19:02:27 +0400
 Subject: [PATCH 1/2] drm/radeon: fix invalid memory access in 
 radeon_atrm_get_bios()

 At a boot time I observed following bug:

  BUG: unable to handle kernel paging request at 8800a4244000
  IP: [81275b5b] memcpy+0xb/0x120
  PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 8000a4244160
  Oops:  [#1] SMP DEBUG_PAGEALLOC
  CPU 0
  Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 
 radeon(+)
  mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
  sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys 
 snd_hda_codec_hdmi
  joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
  snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
  i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw 
 snd_page_alloc
  loop btrfs

  Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046             
               /AMD CRB
  RIP: 0010:[81275b5b]  [81275b5b] memcpy+0xb/0x120
  RSP: 0018:8800aa72db00  EFLAGS: 00010246
  RAX: 8800a415 RBX: 1000 RCX: 0087
  RDX:  RSI: 8800a4244000 RDI: 8800a4150bc8
  RBP: 8800aa72db78 R08: 0010 R09: 8174bbec
  R10: 812ee010 R11: 0001 R12: 1000
  R13: 0001 R14: 8800a414 R15: 8800aaba1800
  FS:  7ff9a3bd4720() GS:8800afa0() knlGS:
  CS:  0010 DS:  ES:  CR0: 8005003b
  CR2: 8800a4244000 CR3: a9c18000 CR4: 06f0
  DR0:  DR1:  DR2: 
  DR3:  DR6: 0ff0 DR7: 0400
  Process modprobe (pid: 1008, threadinfo 8800aa72c000, task 
 8800aa0e4000)
  Stack:
  a04e7c7b 0001 0001 8800aa72db28
  0001 1000 8113cbef 0020
  8800a4243420 8802 8800aa72db08 8800a9d42000
  Call Trace:
  [a04e7c7b] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
  [8113cbef] ? kmalloc_order_trace+0x3f/0xb0
  [a04a9298] radeon_get_bios+0x68/0x2f0 [radeon]
  [a04c7a30] rv770_init+0x40/0x280 [radeon]
  [a047d740] radeon_device_init+0x560/0x600 [radeon]
  [a047ef4f] radeon_driver_load_kms+0xaf/0x170 [radeon]
  [a043cdde] drm_get_pci_dev+0x18e/0x2c0 [drm]
  [a04e7e95] radeon_pci_probe+0xad/0xb5 [radeon]
  [81296c5f] local_pci_probe+0x5f/0xd0
  [81297418] pci_device_probe+0x88/0xb0
  [813417aa] ? driver_sysfs_add+0x7a/0xb0
  [813418d8] really_probe+0x68/0x180
  [81341be5] driver_probe_device+0x45/0x70
  [81341cb3] __driver_attach+0xa3/0xb0
  [81341c10] ? driver_probe_device+0x70/0x70
  [813400ce] bus_for_each_dev+0x5e/0x90
  [8134172e] driver_attach+0x1e/0x20
  [81341298] bus_add_driver+0xc8/0x280
  [813422c6] driver_register+0x76/0x140
  [812976d6] __pci_register_driver+0x66/0xe0
  [a043d021] drm_pci_init+0x111/0x120 [drm]
  [8133c67a] ? vga_switcheroo_register_handler+0x3a/0x60
  [a0229000] ? 0xa0228fff
  [a02290ec] radeon_init+0xec/0xee [radeon]
  [810002f2] do_one_initcall+0x42/0x180
  [8109d8d2] sys_init_module+0x92/0x1e0
  [815407a9] system_call_fastpath+0x16/0x1b
  Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
  e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 f3 48
  a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
  RIP  [81275b5b] memcpy+0xb/0x120
  RSP 8800aa72db00
  CR2: 8800a4244000
  ---[ end trace fcffa1599cf56382 ]---

 Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
 on my system it can return 2048 bytes chunk, so pass the length of
 retrieved chunk to memcpy(), not the length of the recieving buffer.

 Signed-off-by: Igor Murzov e-m...@date.by

Both patches are:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/radeon_atpx_handler.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
 b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
 index 9d95792..c666a5b 100644
 --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
 +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
 @@ -58,7 +58,7 @@ static int radeon_atrm_call(acpi_handle atrm_handle, 
 uint8_t *bios,
        }

        obj = (union acpi_object *)buffer.pointer;
 -       memcpy(bios+offset, obj-buffer.pointer, len);
 +       memcpy(bios+offset, obj-buffer.pointer, 

[Bug 44919] Wayland clients segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

--- Comment #9 from Alex Deucher ag...@yahoo.com 2012-01-24 06:15:48 PST ---
Possible fix:
http://lists.freedesktop.org/archives/mesa-dev/2012-January/018029.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

--- Comment #5 from Fabio Pedretti fabio@libero.it 2012-01-24 06:18:21 
PST ---
(In reply to comment #4)
 Is this still an issue with the latest mesa git?

Yes

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix authentication kernel crash

[Daniel Vetter]

On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
 If the master tries to authenticate a client using drm_authmagic and
 that client has already closed its drm file descriptor,
 either wilfully or because it was terminated, the
 call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
 and corrupt it.
 
 Typically this results in a hard system hang.
 
 This patch fixes that problem by removing any authentication tokens
 (struct drm_magic_entry) open for a file descriptor when that file
 descriptor is closed.
 
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com

Ok, I've wandered around a bit in this and noticed that the locking is the
usual convoluted disaster. We seem to randomly grab dev-struct_mutex in
the auth and master ioctl, but all the real protect seems to be due to
taking the global mutex in all relevant paths.

I guess I can't volunteer you to clean this up ;-)

Otherwise I couldn't poke a hole into this, so
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
  
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

new GPU hang [was: g33: GPU hangs]

[Jiri Slaby]

On 01/18/2012 12:43 PM, Daniel Vetter wrote:
 From 2b76187d2f5fc2352e391914b1828f91f93bb356 Mon Sep 17 00:00:00 2001
 From: Chris Wilson ch...@chris-wilson.co.uk
 Date: Tue, 29 Nov 2011 15:12:16 +
 Subject: [PATCH] drm/i915: Only clear the GPU domains upon a successful
  finish

 Hi, do you plan to push this patch upstream? Or am I supposed to not use
 it anymore?
 
 It's on track to get merged to drm-intel-next. I'll probably pick it up in a 
 week
 or so.

OK, thanks.

Even though I use the patch, today another hang occurred:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting
910502 at 910475, next 910519)
[drm:i915_reset] *ERROR* Failed to reset chip.

I was cruising through a map at openstreetmaps.org. This was
3.2.0-next-20120118_64+. FWIW I updated to 3.3.0-rc1-next-20120124_64+
right now.

Is it related to the bug I reported at:
https://bugs.freedesktop.org/show_bug.cgi?id=43427
?

dmesg:
http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state.dmesg

error_state:
http://www.fi.muni.cz/~xslaby/sklad/panics/915_error_state

thanks,
-- 
js
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40034] E-350 misprocesses shader

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40034

--- Comment #10 from Lauri Kasanen cur...@operamail.com 2012-01-24 07:11:39 
PST ---
I can test on the weekend.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Looking for libsegfault

[Jerome Glisse]

2012/1/24 Rafał Miłecki zaj...@gmail.com:
 Hey,

 I want to do some RE-ing and I'm looking for libsegfault to trace Xorg
 driver ops. Unfortunately I can't find libsegfault at
 http://people.freedesktop.org/~glisse/ anymore.

 Can someone share this, please?

 --
 Rafał

You better of using valgrind. I am not even sure the trick used in
libsegfault work anymore also it was only for x86 kernel.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix ttm move notify callback

[Konrad Rzeszutek Wilk]

On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
 On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
  On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
Still having difficulty to reproduce can you reproduce with the attached
printk debuging patch and provide the log (only few printk preceding the
oops or segfault are interesting).
   
   http://darnok.org/vga/move_notify-v212.log
   
  
  Looks like nouveau doesn't like move notify being call on driver
  shutdown or when somethings om nv50 is down. Ben i think you will
  be better at finding a fix for that than me.
 I'm also not able to reproduce this issue on a NV98 (so, i'd expect
 every nv50+ chipset to behave the same) chipset with the current code in
 Dave's drm-core-next tree..

There looks to be a bug about this openned when folks where using firefox
and seeing large pictures or scrolling through a large web-page.

Any thoughts or things I could try out to narrow this down?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..

 Why?

 I guess drm.o is ending up in a module, but the code that calls that
 (in common.c) is not in a module, so you get an unresolved symbol at
 link

Right... But that code can be moved as well. Just like with the bridge.

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44919] Wayland clients segfault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44919

--- Comment #10 from Scott Moreau ore...@gmail.com 2012-01-24 07:56:34 PST ---
(In reply to comment #9)
 Possible fix:
 http://lists.freedesktop.org/archives/mesa-dev/2012-January/018029.html

I tested this patch and it solves the issue with weston clients here on r300g.
Thanks Alex.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: add support for streamout v2

[alexdeucher]

From: Marek Olšák mar...@gmail.com

v2: agd5f: add strmout CS checking, copy_dw register checking

Signed-off-by: Marek Olšák mar...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  114 +--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  123 -
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 +++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 +++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 +++
 8 files changed, 271 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..1e23c3c 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-db_s_write_offset = 0x;
track-db_s_read_bo = NULL;
track-db_s_write_bo = NULL;
+
+   for (i = 0; i  4; i++) {
+   track-vgt_strmout_size[i] = 0;
+   track-vgt_strmout_bo[i] = NULL;
+   track-vgt_strmout_bo_offset[i] = 0x;
+   track-vgt_strmout_bo_mc[i] = 0x;
+   }
 }
 
 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p-track;
-
-   /* we don't support stream out buffer yet */
-   if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
-   dev_warn(p-dev, this kernel doesn't support SMX output 
buffer\n);
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, bad SET_CONTEXT_REG 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
 8;
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
+   track-vgt_strmout_bo[tmp] = reloc-robj;
+   track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, missing reloc for CP_COHER_BASE 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
case CB_TARGET_MASK:
track-cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1451,6 +1485,70 @@ static int evergreen_packet3_check(struct 
radeon_cs_parser *p,
return -EINVAL;
}
break;
+   case PACKET3_STRMOUT_BUFFER_UPDATE:
+   if (pkt-count != 4) {
+   DRM_ERROR(bad STRMOUT_BUFFER_UPDATE (invalid 
count)\n);
+   return -EINVAL;
+   }
+   /* Updating memory at DST_ADDRESS. */
+   if (idx_value  0x1) {
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   DRM_ERROR(bad STRMOUT_BUFFER_UPDATE (missing 
reloc 1)\n);
+   return -EINVAL;
+

[Bug 40776] [r300g] games crash with pp_jimenezmlaa=8

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40776

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-01-24 09:07:22 PST 
---
Fixed in commit 7219af5ec184d4f92682e75f3d992ae048005d6a ('gallium/postprocess:
Proper reference counting of pp_jimenezmlaa depth buffer.')

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: silence out possible lock dependency warning

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

Silence out the lock dependency warning by moving bo allocation out
of ib mutex protected section. Might lead to useless temporary
allocation but it's not harmful as such things only happen at
initialization.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_ring.c |   19 +++
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index e8bc709..1cb4b94 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -204,22 +204,25 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct 
radeon_ib *ib)
 
 int radeon_ib_pool_init(struct radeon_device *rdev)
 {
+   struct radeon_sa_manager tmp;
int i, r;
 
-   mutex_lock(rdev-ib_pool.mutex);
-   if (rdev-ib_pool.ready) {
-   mutex_unlock(rdev-ib_pool.mutex);
-   return 0;
-   }
-
-   r = radeon_sa_bo_manager_init(rdev, rdev-ib_pool.sa_manager,
+   r = radeon_sa_bo_manager_init(rdev, tmp,
  RADEON_IB_POOL_SIZE*64*1024,
  RADEON_GEM_DOMAIN_GTT);
if (r) {
-   mutex_unlock(rdev-ib_pool.mutex);
return r;
}
 
+   mutex_lock(rdev-ib_pool.mutex);
+   if (rdev-ib_pool.ready) {
+   mutex_unlock(rdev-ib_pool.mutex);
+   radeon_sa_bo_manager_fini(rdev, tmp);
+   return 0;
+   }
+
+   rdev-ib_pool.sa_manager = tmp;
+   INIT_LIST_HEAD(rdev-ib_pool.sa_manager.sa_bo);
for (i = 0; i  RADEON_IB_POOL_SIZE; i++) {
rdev-ib_pool.ibs[i].fence = NULL;
rdev-ib_pool.ibs[i].idx = i;
-- 
1.7.7.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix authentication kernel crash

[Greg KH]

On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote:
 If the master tries to authenticate a client using drm_authmagic and
 that client has already closed its drm file descriptor,
 either wilfully or because it was terminated, the
 call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
 and corrupt it.
 
 Typically this results in a hard system hang.
 
 This patch fixes that problem by removing any authentication tokens
 (struct drm_magic_entry) open for a file descriptor when that file
 descriptor is closed.
 
 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 ---
 Please review. This should also go into stable kernels.

formletter

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

/formletter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix authentication kernel crash

[Thomas Hellstrom]

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: sta...@vger.kernel.org
---
Resent with Review-by and Cc added.

 drivers/gpu/drm/drm_auth.c |6 +-
 drivers/gpu/drm/drm_fops.c |5 +
 include/drm/drmP.h |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 3f46772..ba23790 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -101,7 +101,7 @@ static int drm_add_magic(struct drm_master *master, struct 
drm_file *priv,
  * Searches and unlinks the entry in drm_device::magiclist with the magic
  * number hash key, while holding the drm_device::struct_mutex lock.
  */
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
 {
struct drm_magic_entry *pt;
struct drm_hash_item *hash;
@@ -136,6 +136,8 @@ static int drm_remove_magic(struct drm_master *master, 
drm_magic_t magic)
  * If there is a magic number in drm_file::magic then use it, otherwise
  * searches an unique non-zero magic number and add it associating it with \p
  * file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
@@ -173,6 +175,8 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
  * \return zero if authentication successed, or a negative number otherwise.
  *
  * Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_authmagic(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c00cf15..6263b01 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -487,6 +487,11 @@ int drm_release(struct inode *inode, struct file *filp)
  (long)old_encode_dev(file_priv-minor-device),
  dev-open_count);
 
+   /* Release any auth tokens that might point to this file_priv,
+  (do that under the drm_global_mutex) */
+   if (file_priv-magic)
+   (void) drm_remove_magic(file_priv-master, file_priv-magic);
+
/* if the master has gone away we can't do anything with the lock */
if (file_priv-minor-master)
drm_master_release(dev, filp);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76caa67..92f0981 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1328,6 +1328,7 @@ extern int drm_getmagic(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 extern int drm_authmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);
 
 /* Cache management (drm_cache.c) */
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #2 from Simon Deziel simon.dez...@gmail.com  2012-01-24 19:03:24 
---
Created an attachment (id=72183)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=72183)
dmesg without nomodeset

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #3 from Simon Deziel simon.dez...@gmail.com  2012-01-24 19:07:35 
---
I'm observing a similar issue with various kernels from 3.2 to 3.3rc1. This
only manifests when booting a Xen dom0 without nomodeset so I'm not sure
that's actually the same bug.

The console screen gets corrupted at login prompt but is OK before as boot
messages are displayed properly. The video card info is :

$ lspci -nnkx -s 01:00.0
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2
MX/MX 400] [10de:0110] (rev b2)
Subsystem: Micro-Star International Co., Ltd. MSI GeForce2 MX400 Pro32S
[MS-8817] [1462:8817]
Kernel modules: nouveau, nvidiafb, rivafb
00: de 10 10 01 07 00 b0 02 b2 00 00 03 00 20 00 00
10: 00 00 00 dc 08 00 00 d0 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 17 88
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01

The bug was initially opened on Launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917211).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27942] Screen garbled with GeForce 6150 Force 430

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=27942





--- Comment #4 from Simon Deziel simon.dez...@gmail.com  2012-01-24 19:45:48 
---
Please disregard my comments (#2 and #3) as I'm looking at the wrong bug
obviously. My problem is apparently solvable by
https://lkml.org/lkml/2010/12/6/464 as outlined by Konrad Rzeszutek Wilk.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..

 Why?

 I guess drm.o is ending up in a module, but the code that calls that
 (in common.c) is not in a module, so you get an unresolved symbol at
 link

 Right... But that code can be moved as well. Just like with the bridge.

Hmm, looks like for dsp bridge the memory reservation is moved to
devices.c.  Although I'm not entirely sure how that is better... and
there is precedent for both approaches, ie. omapfb works like omapdrm,
and tidspbridge works as you suggest.

seems a bit bikeshed'ish to me

BR,
-R

 --
 Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: add support for streamout v3

[alexdeucher]

From: Marek Olšák mar...@gmail.com

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

Signed-off-by: Marek Olšák mar...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  137 +++--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  136 +++-
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 307 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..7bef5f8 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-db_s_write_offset = 0x;
track-db_s_read_bo = NULL;
track-db_s_write_bo = NULL;
+
+   for (i = 0; i  4; i++) {
+   track-vgt_strmout_size[i] = 0;
+   track-vgt_strmout_bo[i] = NULL;
+   track-vgt_strmout_bo_offset[i] = 0x;
+   track-vgt_strmout_bo_mc[i] = 0x;
+   }
 }
 
 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p-track;
-
-   /* we don't support stream out buffer yet */
-   if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
-   dev_warn(p-dev, this kernel doesn't support SMX output 
buffer\n);
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, bad SET_CONTEXT_REG 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
 8;
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
+   track-vgt_strmout_bo[tmp] = reloc-robj;
+   track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, missing reloc for CP_COHER_BASE 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
case CB_TARGET_MASK:
track-cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1048,31 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }
 
+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p-rdev-family = CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg  7);
+   if (i = last_reg) {
+   dev_warn(p-dev, forbidden register 0x%08x at %d\n, reg, idx);
+   return false;
+   }
+   m = 1  ((reg  2)  31);

[PATCH] drm/radeon/kms: add support for streamout v4

[alexdeucher]

From: Marek Olšák mar...@gmail.com

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

v4: agd5f: add warning if safe reg check fails for copy_dw

Signed-off-by: Marek Olšák mar...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  138 +++--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  137 +++-
 drivers/gpu/drm/radeon/r600d.h|6 ++
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 309 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..8bc883a 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-db_s_write_offset = 0x;
track-db_s_read_bo = NULL;
track-db_s_write_bo = NULL;
+
+   for (i = 0; i  4; i++) {
+   track-vgt_strmout_size[i] = 0;
+   track-vgt_strmout_bo[i] = NULL;
+   track-vgt_strmout_bo_offset[i] = 0x;
+   track-vgt_strmout_bo_mc[i] = 0x;
+   }
 }
 
 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p-track;
-
-   /* we don't support stream out buffer yet */
-   if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
-   dev_warn(p-dev, this kernel doesn't support SMX output 
buffer\n);
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, bad SET_CONTEXT_REG 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
 8;
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
+   track-vgt_strmout_bo[tmp] = reloc-robj;
+   track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, missing reloc for CP_COHER_BASE 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
case CB_TARGET_MASK:
track-cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1048,32 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }
 
+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p-rdev-family = CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg  7);
+   if (i = last_reg) {
+   dev_warn(p-dev, forbidden register 0x%08x at %d\n, reg, idx);
+  

Re: [next] Null pointer dereference in nouveau_vm_map_sg

[Jerome Glisse]

On Sun, Jan 22, 2012 at 01:33:16PM -0500, Konrad Rzeszutek Wilk wrote:
 On Tue, Jan 17, 2012 at 12:57:50AM +0100, Martin Nyhus wrote:
  On Monday 16. January 2012 21:30:59 Jerome Glisse wrote:
   On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
In some cases mem will be null in nouveau_vm_map_sg, resulting in a 
crash
at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough 
to
reproduce, so I can test patches if needed.
   How do you trigger this ?
  
  Opening 10-15 high-res pictures in Firefox triggers it every time. Doing 
  the 
  same using Gimp does not, and neither does Firefox and lots of small images 
  (eg. Google image search).
 
 I seem to be able to trigger this by using both Chrome and Firefox and 
 seeing a YouTube video. I did at that time have a dual-head display, while
 in the past to reproduce this I had only one monitor and it took a bit of
 time before I hit it.

Can you please both test if attached patch fix it for you ?

Cheers,
Jerome
From 67d4836e3511db2691c4ff2d3a23bf8c0e950edb Mon Sep 17 00:00:00 2001
From: John Doe gli...@dhcp-189-215.bos.redhat.com
Date: Tue, 24 Jan 2012 22:55:26 -0500
Subject: [PATCH] drm/nouveau: fix move notify callback

On vram buffer eviction the ttm_bo_move_accel_cleanup will the
mm_node field of struct ttm_mem_reg of new_mem placement to NULL.
As move notify call back is now call after ttm_bo_move_accel_cleanup
it was using NULL ptr for mm_node.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..3a9d978 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -814,13 +814,13 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
 
list_for_each_entry(vma, nvbo-vma_list, head) {
if (new_mem  new_mem-mem_type == TTM_PL_VRAM) {
-   nouveau_vm_map(vma, new_mem-mm_node);
+   nouveau_vm_map(vma, bo-mem.mm_node);
} else
if (new_mem  new_mem-mem_type == TTM_PL_TT 
nvbo-page_shift == vma-vm-spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem-
  num_pages  PAGE_SHIFT,
- new_mem-mm_node);
+ bo-mem.mm_node);
} else {
nouveau_vm_unmap(vma);
}
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=39832





--- Comment #18 from Florian Mickler flor...@mickler.org  2012-01-24 23:15:56 
---
Is this still a problem in 3.2 / 3.3-rc1?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: add support for streamout v4

[Jerome Glisse]

On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeuc...@gmail.com wrote:
 From: Marek Olšák mar...@gmail.com
 
 v2: agd5f: add strmout CS checking, copy_dw register checking
 
 v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
 will incorrectly patch the command stream for certain regs.
 
 v4: agd5f: add warning if safe reg check fails for copy_dw

NAK

You never check the stream out buffer size and you never check that
the memory offset for dw copy is not after the bo end. See comment
below. Sorry to not just do a v5 busy with ttm :(

Beside this it looks ok.

Cheers,
Jerome

 
 Signed-off-by: Marek Olšák mar...@gmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/evergreen_cs.c |  138 
 +++--
  drivers/gpu/drm/radeon/evergreend.h   |9 ++
  drivers/gpu/drm/radeon/r600_cs.c  |  137 +++-
  drivers/gpu/drm/radeon/r600d.h|6 ++
  drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
  drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
  drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
  drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
  8 files changed, 309 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index f7442e6..8bc883a 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -60,6 +60,10 @@ struct evergreen_cs_track {
   u32 cb_shader_mask;
   u32 vgt_strmout_config;
   u32 vgt_strmout_buffer_config;
 + struct radeon_bo*vgt_strmout_bo[4];
 + u64 vgt_strmout_bo_mc[4];
 + u32 vgt_strmout_bo_offset[4];
 + u32 vgt_strmout_size[4];
   u32 db_depth_control;
   u32 db_depth_view;
   u32 db_depth_size;
 @@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
 evergreen_cs_track *track)
   track-db_s_write_offset = 0x;
   track-db_s_read_bo = NULL;
   track-db_s_write_bo = NULL;
 +
 + for (i = 0; i  4; i++) {
 + track-vgt_strmout_size[i] = 0;
 + track-vgt_strmout_bo[i] = NULL;
 + track-vgt_strmout_bo_offset[i] = 0x;
 + track-vgt_strmout_bo_mc[i] = 0x;
 + }
  }
  
  static int evergreen_cs_track_check(struct radeon_cs_parser *p)
  {
 - struct evergreen_cs_track *track = p-track;
 -
 - /* we don't support stream out buffer yet */
 - if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
 - dev_warn(p-dev, this kernel doesn't support SMX output 
 buffer\n);
 - return -EINVAL;
 - }
 -
   /* XXX fill in */
   return 0;
  }
 @@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct 
 radeon_cs_parser *p, u32 reg, u32 idx)
   case VGT_STRMOUT_BUFFER_CONFIG:
   track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
   break;
 + case VGT_STRMOUT_BUFFER_BASE_0:
 + case VGT_STRMOUT_BUFFER_BASE_1:
 + case VGT_STRMOUT_BUFFER_BASE_2:
 + case VGT_STRMOUT_BUFFER_BASE_3:
 + r = evergreen_cs_packet_next_reloc(p, reloc);
 + if (r) {
 + dev_warn(p-dev, bad SET_CONTEXT_REG 
 + 0x%04X\n, reg);
 + return -EINVAL;
 + }
 + tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
 + track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
  8;
 + ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
 + track-vgt_strmout_bo[tmp] = reloc-robj;
 + track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
 + break;
 + case VGT_STRMOUT_BUFFER_SIZE_0:
 + case VGT_STRMOUT_BUFFER_SIZE_1:
 + case VGT_STRMOUT_BUFFER_SIZE_2:
 + case VGT_STRMOUT_BUFFER_SIZE_3:
 + tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
 + track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);

r6xx path divide this value by 4 but you never check that :
track-vgt_strmout_bo_offset[tmp] + track-vgt_strmout_size = bo.size

 + break;
 + case CP_COHER_BASE:
 + r = evergreen_cs_packet_next_reloc(p, reloc);
 + if (r) {
 + dev_warn(p-dev, missing reloc for CP_COHER_BASE 
 + 0x%04X\n, reg);
 + return -EINVAL;
 + }
 + ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
   case CB_TARGET_MASK:
   track-cb_target_mask = radeon_get_ib_value(p, idx);
   break;
 @@ -1014,6 +1048,32 @@ static int evergreen_check_texture_resource(struct 
 radeon_cs_parser *p,  u32 idx
   return 0;
  }
  
 +static 

Re: [PATCH] drm/radeon: silence out possible lock dependency warning

[Alexandre Demers]

I suppose I can stop bisecting kernel about this possible lock and close
the bug then?

-- 
Alexandre Demers

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: add support for streamout v4

[Marek Olšák]

Sorry Jerome, I didn't have time to properly finish the patch and
update the CS checker properly.

Also evergreen_cs_track_check has been a no-op for a long time and
this patch doesn't make it any more exploitable.

Marek

On Wed, Jan 25, 2012 at 12:43 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeuc...@gmail.com wrote:
 From: Marek Olšák mar...@gmail.com

 v2: agd5f: add strmout CS checking, copy_dw register checking

 v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
 will incorrectly patch the command stream for certain regs.

 v4: agd5f: add warning if safe reg check fails for copy_dw

 NAK

 You never check the stream out buffer size and you never check that
 the memory offset for dw copy is not after the bo end. See comment
 below. Sorry to not just do a v5 busy with ttm :(

 Beside this it looks ok.

 Cheers,
 Jerome


 Signed-off-by: Marek Olšák mar...@gmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/evergreen_cs.c     |  138 
 +++--
  drivers/gpu/drm/radeon/evergreend.h       |    9 ++
  drivers/gpu/drm/radeon/r600_cs.c          |  137 
 +++-
  drivers/gpu/drm/radeon/r600d.h            |    6 ++
  drivers/gpu/drm/radeon/radeon_drv.c       |    2 +-
  drivers/gpu/drm/radeon/reg_srcs/cayman    |   10 ++
  drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
  drivers/gpu/drm/radeon/reg_srcs/r600      |   10 ++
  8 files changed, 309 insertions(+), 13 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index f7442e6..8bc883a 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -60,6 +60,10 @@ struct evergreen_cs_track {
       u32                     cb_shader_mask;
       u32                     vgt_strmout_config;
       u32                     vgt_strmout_buffer_config;
 +     struct radeon_bo        *vgt_strmout_bo[4];
 +     u64                     vgt_strmout_bo_mc[4];
 +     u32                     vgt_strmout_bo_offset[4];
 +     u32                     vgt_strmout_size[4];
       u32                     db_depth_control;
       u32                     db_depth_view;
       u32                     db_depth_size;
 @@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
 evergreen_cs_track *track)
       track-db_s_write_offset = 0x;
       track-db_s_read_bo = NULL;
       track-db_s_write_bo = NULL;
 +
 +     for (i = 0; i  4; i++) {
 +             track-vgt_strmout_size[i] = 0;
 +             track-vgt_strmout_bo[i] = NULL;
 +             track-vgt_strmout_bo_offset[i] = 0x;
 +             track-vgt_strmout_bo_mc[i] = 0x;
 +     }
  }

  static int evergreen_cs_track_check(struct radeon_cs_parser *p)
  {
 -     struct evergreen_cs_track *track = p-track;
 -
 -     /* we don't support stream out buffer yet */
 -     if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
 -             dev_warn(p-dev, this kernel doesn't support SMX output 
 buffer\n);
 -             return -EINVAL;
 -     }
 -
       /* XXX fill in */
       return 0;
  }
 @@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct 
 radeon_cs_parser *p, u32 reg, u32 idx)
       case VGT_STRMOUT_BUFFER_CONFIG:
               track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
               break;
 +     case VGT_STRMOUT_BUFFER_BASE_0:
 +     case VGT_STRMOUT_BUFFER_BASE_1:
 +     case VGT_STRMOUT_BUFFER_BASE_2:
 +     case VGT_STRMOUT_BUFFER_BASE_3:
 +             r = evergreen_cs_packet_next_reloc(p, reloc);
 +             if (r) {
 +                     dev_warn(p-dev, bad SET_CONTEXT_REG 
 +                                     0x%04X\n, reg);
 +                     return -EINVAL;
 +             }
 +             tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
 +             track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, 
 idx)  8;
 +             ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
 +             track-vgt_strmout_bo[tmp] = reloc-robj;
 +             track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
 +             break;
 +     case VGT_STRMOUT_BUFFER_SIZE_0:
 +     case VGT_STRMOUT_BUFFER_SIZE_1:
 +     case VGT_STRMOUT_BUFFER_SIZE_2:
 +     case VGT_STRMOUT_BUFFER_SIZE_3:
 +             tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
 +             track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);

 r6xx path divide this value by 4 but you never check that :
 track-vgt_strmout_bo_offset[tmp] + track-vgt_strmout_size = bo.size

 +             break;
 +     case CP_COHER_BASE:
 +             r = evergreen_cs_packet_next_reloc(p, reloc);
 +             if (r) {
 +                     dev_warn(p-dev, missing reloc for CP_COHER_BASE 
 +                                     0x%04X\n, reg);
 +                     return -EINVAL;
 +             }
 +             ib[idx] += 

[PATCH] drm/radeon/kms: add support for streamout v5

[alexdeucher]

From: Marek Olšák mar...@gmail.com

v2: agd5f: add strmout CS checking, copy_dw register checking

v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.

v4: agd5f: add warning if safe reg check fails for copy_dw

v5: agd5f: add stricter checking for 6xx/7xx

Signed-off-by: Marek Olšák mar...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c |  139 +--
 drivers/gpu/drm/radeon/evergreend.h   |9 ++
 drivers/gpu/drm/radeon/r600_cs.c  |  179 -
 drivers/gpu/drm/radeon/r600d.h|6 +
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/reg_srcs/cayman|   10 ++
 drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
 drivers/gpu/drm/radeon/reg_srcs/r600  |   10 ++
 8 files changed, 352 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f7442e6..30d4a2e 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -60,6 +60,10 @@ struct evergreen_cs_track {
u32 cb_shader_mask;
u32 vgt_strmout_config;
u32 vgt_strmout_buffer_config;
+   struct radeon_bo*vgt_strmout_bo[4];
+   u64 vgt_strmout_bo_mc[4];
+   u32 vgt_strmout_bo_offset[4];
+   u32 vgt_strmout_size[4];
u32 db_depth_control;
u32 db_depth_view;
u32 db_depth_size;
@@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-db_s_write_offset = 0x;
track-db_s_read_bo = NULL;
track-db_s_write_bo = NULL;
+
+   for (i = 0; i  4; i++) {
+   track-vgt_strmout_size[i] = 0;
+   track-vgt_strmout_bo[i] = NULL;
+   track-vgt_strmout_bo_offset[i] = 0x;
+   track-vgt_strmout_bo_mc[i] = 0x;
+   }
 }
 
 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
-   struct evergreen_cs_track *track = p-track;
-
-   /* we don't support stream out buffer yet */
-   if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
-   dev_warn(p-dev, this kernel doesn't support SMX output 
buffer\n);
-   return -EINVAL;
-   }
-
/* XXX fill in */
return 0;
 }
@@ -597,6 +600,38 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
case VGT_STRMOUT_BUFFER_CONFIG:
track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
break;
+   case VGT_STRMOUT_BUFFER_BASE_0:
+   case VGT_STRMOUT_BUFFER_BASE_1:
+   case VGT_STRMOUT_BUFFER_BASE_2:
+   case VGT_STRMOUT_BUFFER_BASE_3:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, bad SET_CONTEXT_REG 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
+   track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, idx) 
 8;
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
+   track-vgt_strmout_bo[tmp] = reloc-robj;
+   track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
+   break;
+   case VGT_STRMOUT_BUFFER_SIZE_0:
+   case VGT_STRMOUT_BUFFER_SIZE_1:
+   case VGT_STRMOUT_BUFFER_SIZE_2:
+   case VGT_STRMOUT_BUFFER_SIZE_3:
+   tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
+   /* size in register is DWs, convert to bytes */
+   track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx) * 4;
+   break;
+   case CP_COHER_BASE:
+   r = evergreen_cs_packet_next_reloc(p, reloc);
+   if (r) {
+   dev_warn(p-dev, missing reloc for CP_COHER_BASE 
+   0x%04X\n, reg);
+   return -EINVAL;
+   }
+   ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
case CB_TARGET_MASK:
track-cb_target_mask = radeon_get_ib_value(p, idx);
break;
@@ -1014,6 +1049,32 @@ static int evergreen_check_texture_resource(struct 
radeon_cs_parser *p,  u32 idx
return 0;
 }
 
+static bool evergreen_is_safe_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
+{
+   u32 last_reg, m, i;
+
+   if (p-rdev-family = CHIP_CAYMAN)
+   last_reg = ARRAY_SIZE(cayman_reg_safe_bm);
+   else
+   last_reg = ARRAY_SIZE(evergreen_reg_safe_bm);
+
+   i = (reg  7);
+   

Re: [PATCH] drm/radeon/kms: add support for streamout v4

[Alex Deucher]

On Tue, Jan 24, 2012 at 6:43 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Tue, Jan 24, 2012 at 05:17:18PM -0500, alexdeuc...@gmail.com wrote:
 From: Marek Olšák mar...@gmail.com

 v2: agd5f: add strmout CS checking, copy_dw register checking

 v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
 will incorrectly patch the command stream for certain regs.

 v4: agd5f: add warning if safe reg check fails for copy_dw

 NAK

 You never check the stream out buffer size and you never check that
 the memory offset for dw copy is not after the bo end. See comment
 below. Sorry to not just do a v5 busy with ttm :(


I just sent out a new version which should address everything.  I went
ahead and implemented strict checking for 6xx/7xx.  I guess my main
concern with the strict checking on 6xx/7xx is that we will miss
corner cases have to revisit it later.  We've already had to revisit
the cb, db, and texture code in the cs checker to work around corner
cases and userspace problems and we will need to yet again for 2D
tiling.  I'm not sure the additional overhead and pain actually makes
things much safer considering how temperamental GPUs are in general.

Alex

 Beside this it looks ok.

 Cheers,
 Jerome


 Signed-off-by: Marek Olšák mar...@gmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/evergreen_cs.c     |  138 
 +++--
  drivers/gpu/drm/radeon/evergreend.h       |    9 ++
  drivers/gpu/drm/radeon/r600_cs.c          |  137 
 +++-
  drivers/gpu/drm/radeon/r600d.h            |    6 ++
  drivers/gpu/drm/radeon/radeon_drv.c       |    2 +-
  drivers/gpu/drm/radeon/reg_srcs/cayman    |   10 ++
  drivers/gpu/drm/radeon/reg_srcs/evergreen |   10 ++
  drivers/gpu/drm/radeon/reg_srcs/r600      |   10 ++
  8 files changed, 309 insertions(+), 13 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index f7442e6..8bc883a 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -60,6 +60,10 @@ struct evergreen_cs_track {
       u32                     cb_shader_mask;
       u32                     vgt_strmout_config;
       u32                     vgt_strmout_buffer_config;
 +     struct radeon_bo        *vgt_strmout_bo[4];
 +     u64                     vgt_strmout_bo_mc[4];
 +     u32                     vgt_strmout_bo_offset[4];
 +     u32                     vgt_strmout_size[4];
       u32                     db_depth_control;
       u32                     db_depth_view;
       u32                     db_depth_size;
 @@ -159,18 +163,17 @@ static void evergreen_cs_track_init(struct 
 evergreen_cs_track *track)
       track-db_s_write_offset = 0x;
       track-db_s_read_bo = NULL;
       track-db_s_write_bo = NULL;
 +
 +     for (i = 0; i  4; i++) {
 +             track-vgt_strmout_size[i] = 0;
 +             track-vgt_strmout_bo[i] = NULL;
 +             track-vgt_strmout_bo_offset[i] = 0x;
 +             track-vgt_strmout_bo_mc[i] = 0x;
 +     }
  }

  static int evergreen_cs_track_check(struct radeon_cs_parser *p)
  {
 -     struct evergreen_cs_track *track = p-track;
 -
 -     /* we don't support stream out buffer yet */
 -     if (track-vgt_strmout_config || track-vgt_strmout_buffer_config) {
 -             dev_warn(p-dev, this kernel doesn't support SMX output 
 buffer\n);
 -             return -EINVAL;
 -     }
 -
       /* XXX fill in */
       return 0;
  }
 @@ -597,6 +600,37 @@ static int evergreen_cs_check_reg(struct 
 radeon_cs_parser *p, u32 reg, u32 idx)
       case VGT_STRMOUT_BUFFER_CONFIG:
               track-vgt_strmout_buffer_config = radeon_get_ib_value(p, idx);
               break;
 +     case VGT_STRMOUT_BUFFER_BASE_0:
 +     case VGT_STRMOUT_BUFFER_BASE_1:
 +     case VGT_STRMOUT_BUFFER_BASE_2:
 +     case VGT_STRMOUT_BUFFER_BASE_3:
 +             r = evergreen_cs_packet_next_reloc(p, reloc);
 +             if (r) {
 +                     dev_warn(p-dev, bad SET_CONTEXT_REG 
 +                                     0x%04X\n, reg);
 +                     return -EINVAL;
 +             }
 +             tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
 +             track-vgt_strmout_bo_offset[tmp] = radeon_get_ib_value(p, 
 idx)  8;
 +             ib[idx] += (u32)((reloc-lobj.gpu_offset  8)  0x);
 +             track-vgt_strmout_bo[tmp] = reloc-robj;
 +             track-vgt_strmout_bo_mc[tmp] = reloc-lobj.gpu_offset;
 +             break;
 +     case VGT_STRMOUT_BUFFER_SIZE_0:
 +     case VGT_STRMOUT_BUFFER_SIZE_1:
 +     case VGT_STRMOUT_BUFFER_SIZE_2:
 +     case VGT_STRMOUT_BUFFER_SIZE_3:
 +             tmp = (reg - VGT_STRMOUT_BUFFER_SIZE_0) / 16;
 +             track-vgt_strmout_size[tmp] = radeon_get_ib_value(p, idx);

 r6xx path divide this value by 4 but you never check that :
 track-vgt_strmout_bo_offset[tmp] + track-vgt_strmout_size = bo.size

 +             

Re: [PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..

 Why?

 I guess drm.o is ending up in a module, but the code that calls that
 (in common.c) is not in a module, so you get an unresolved symbol at
 link

 Right... But that code can be moved as well. Just like with the bridge.

 Hmm, looks like for dsp bridge the memory reservation is moved to
 devices.c.  Although I'm not entirely sure how that is better... and
 there is precedent for both approaches, ie. omapfb works like omapdrm,
 and tidspbridge works as you suggest.

 seems a bit bikeshed'ish to me

I will send a patch to fix omapfb, perhaps after that it will be a bit
more clear how it should be done :) (if it gets accepted)

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..

 Why?

 I guess drm.o is ending up in a module, but the code that calls that
 (in common.c) is not in a module, so you get an unresolved symbol at
 link

 Right... But that code can be moved as well. Just like with the bridge.

 Hmm, looks like for dsp bridge the memory reservation is moved to
 devices.c.  Although I'm not entirely sure how that is better... and
 there is precedent for both approaches, ie. omapfb works like omapdrm,
 and tidspbridge works as you suggest.

 seems a bit bikeshed'ish to me

 I will send a patch to fix omapfb, perhaps after that it will be a bit
 more clear how it should be done :) (if it gets accepted)

ok, but the thing I don't like is it splits up the drm device setup
from the omapdrm_reserve_vram() part (and similarly for omapfb),

but if this is the consensus of how it should be done, well.. when in
Rome, and all that

BR,
-R

 --
 Felipe Contreras
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: fix two regressions since move_notify changes

[Ben Skeggs]

From: Ben Skeggs bske...@redhat.com

Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.

move_notify() was originally able to presume that bo-mem is the old node,
and new_mem is the new node.  The above commit moves the call to
move_notify() to after move() has been done, which means that now, sometimes,
new_mem isn't the new node at all, bo-mem is, and new_mem points at a
stale, possibly-just-been-killed-by-move node.

This is clearly not a good situation.  This patch reverts this change, and
replaces it with a cleanup in the move() failure path instead.

The second issue is that the call to move_notify() from cleanup_memtype_use()
causes the TTM ghost objects to get passed into the driver.  This is clearly
bad as the driver knows nothing about these fake TTM BOs, and ends up
accessing uninitialised memory.

I worked around this in nouveau's move_notify() hook by ensuring the BO
destructor was nouveau's.  I don't particularly like this solution, and
would rather TTM never pass the driver these objects.  However, I don't
clearly understand the reason why we're calling move_notify() here anyway
and am happy to work around the problem in nouveau instead of breaking the
behaviour expected by other drivers.

Signed-off-by: Ben Skeggs bske...@redhat.com
Cc: Jerome Glisse j.gli...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |4 
 drivers/gpu/drm/ttm/ttm_bo.c |   17 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 724b41a..ec54364 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -812,6 +812,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem)
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_vma *vma;
 
+   /* ttm can now (stupidly) pass the driver bos it didn't create... */
+   if (bo-destroy != nouveau_bo_del_ttm)
+   return;
+
list_for_each_entry(vma, nvbo-vma_list, head) {
if (new_mem  new_mem-mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem-mm_node);
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2f0eab6..7c3a57d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -404,6 +404,9 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
}
}
 
+   if (bdev-driver-move_notify)
+   bdev-driver-move_notify(bo, mem);
+
if (!(old_man-flags  TTM_MEMTYPE_FLAG_FIXED) 
!(new_man-flags  TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu, 
mem);
@@ -413,11 +416,17 @@ static int ttm_bo_handle_move_mem(struct 
ttm_buffer_object *bo,
else
ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
no_wait_gpu, mem);
 
-   if (ret)
-   goto out_err;
+   if (ret) {
+   if (bdev-driver-move_notify) {
+   struct ttm_mem_reg tmp_mem = *mem;
+   *mem = bo-mem;
+   bo-mem = tmp_mem;
+   bdev-driver-move_notify(bo, mem);
+   bo-mem = *mem;
+   }
 
-   if (bdev-driver-move_notify)
-   bdev-driver-move_notify(bo, mem);
+   goto out_err;
+   }
 
 moved:
if (bo-evicted) {
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

[Semwal, Sumit]

On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
 On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
  On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
   EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
   issue, and not really an interface.  The dma-buf infrastructure is
   explicitly intended as an interface between modules/drivers, so it
   should use EXPORT_SYMBOL instead.
 
  + Konrad, Arnd, Mauro: there were strong objections on using
  EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I
  suggest we first arrive at a consensus before merging this patch.

 This discussion seems to have stagnated; how do we move forward here?

 Sumit, as the primary author and new maintainer (congrats!) of the
 dma-buf infrastructure, it seems like it's really your call how to
 proceed.  I'd still like to see this be something that we can use from
 the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have
 argued in this thread.  It really seems to me that this change on a
 technical level won't have any adverse effect on the scenarios where it
 can be used today, but it will allow it to be used more widely, which
 will prevent duplication and fragmentation in the future and be greatly
 appreciated by users of hardware such as Optimus.

 Given that I've participated quite a bit in the design of dma_buf as-is,
 let me throw in my totally irrelevant opinion, too ;-)

 I'll refrain from comment on the actual patch, it's obviously a hot topic.
 Furthermore I might need to ask Intel's legal dep for guidance to asses
 things wrt my own contributions to dma_buf.

 Otoh I'd like nvidia to be on board, especially when we're desingned
 additions to dma_buf required to make it really work for multiple gpus. In
 additions it looks like that the nvidia blob will only be an importer of a
 dma_buf, at least for the use-cases discussed here.

 So why don't you just ditch this patch here and add a small shim to your
 blob to interface with drm's prime as an importing driver? I personally
 would deem that acceptable and I think Dave wouldn't mind too much,
 either.

Hi Everyone!

(Apologies for delay in replying; was OoO for past couple of days)

Thanks very much for this discussion - a couple of things:

1. I am definitely willing to make changes as needed to get as many
devices / subsystems / frameworks to use the dma-buf infrastructure.
This could include changing the way symbols are exported, if that is
the *only* way to get things done.

2. With that premise, I quite like the idea that Daniel gave (of
course, in his capacity as one of the top contributors behind dma-buf
infrastructure, and like he said, not as an Intel employee) - so let
me ask the following:

Robert, Dave,
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this approach?

Also, if some of you are going to be at ELC mid-Feb at SFO, we could
meet up face-to-face and thrash out possible ways forward.

 Yours, Daniel
Thanks, and best regards,
~Sumit.

 Disclaimer: This is my own opinion and I do not speak as an Intel employee
 here.
 --
 Daniel Vetter
 Mail: dan...@ffwll.ch
 Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel