dri-devel December 2012

dri-devel@lists.freedesktop.org

121 participants
687 discussions

[Bug 55416] New: [R600g] Torchlight gives GPU lockup
by bugzilla-daemon＠freedesktop.org 11 Dec '12

11 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=55416 Priority: medium Bug ID: 55416 Assignee: dri-devel(a)lists.freedesktop.org Summary: [R600g] Torchlight gives GPU lockup Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lordheavym(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When i try to play the game (after character selection),i've got several GPU lockup until i kill the game: dmesg: --8<-- [ 900.867633] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 900.867645] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000012fb4 last fence id 0x0000000000012faa) [ 900.868726] radeon 0000:01:00.0: GPU softreset [ 900.868732] radeon 0000:01:00.0: GRBM_STATUS=0xE7730828 [ 900.868737] radeon 0000:01:00.0: GRBM_STATUS_SE0=0xFC000001 [ 900.868743] radeon 0000:01:00.0: GRBM_STATUS_SE1=0xFC000001 [ 900.868748] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 900.868756] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B [ 900.868863] radeon 0000:01:00.0: GRBM_STATUS=0x00003828 [ 900.868868] radeon 0000:01:00.0: GRBM_STATUS_SE0=0x00000007 [ 900.868873] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000007 [ 900.868878] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 900.869884] radeon 0000:01:00.0: GPU reset succeed [ 900.878264] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 900.878371] radeon 0000:01:00.0: WB enabled [ 900.878379] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802218a5c00 [ 900.894717] [drm] ring test on 0 succeeded in 2 usecs [ 900.894770] [drm] ib test on ring 0 succeeded in 0 usecs [ 911.968025] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 911.968038] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000013018 last fence id 0x0000000000013014) [ 911.969149] radeon 0000:01:00.0: GPU softreset [ 911.969155] radeon 0000:01:00.0: GRBM_STATUS=0xE7730828 [ 911.969161] radeon 0000:01:00.0: GRBM_STATUS_SE0=0xFC000001 [ 911.969167] radeon 0000:01:00.0: GRBM_STATUS_SE1=0xFC000001 [ 911.969172] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 911.969183] radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B [ 911.969291] radeon 0000:01:00.0: GRBM_STATUS=0x00003828 [ 911.969297] radeon 0000:01:00.0: GRBM_STATUS_SE0=0x00000007 [ 911.969302] radeon 0000:01:00.0: GRBM_STATUS_SE1=0x00000007 [ 911.969307] radeon 0000:01:00.0: SRBM_STATUS=0x200000C0 [ 911.970313] radeon 0000:01:00.0: GPU reset succeed [ 911.978920] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 911.979030] radeon 0000:01:00.0: WB enabled [ 911.979039] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802218a5c00 [ 911.995378] [drm] ring test on 0 succeeded in 2 usecs [ 911.995432] [drm] ib test on ring 0 succeeded in 0 usecs -->8-- uname -a: Linux archMain 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 9.1-devel (git-124b214) OpenGL shading language version string: 1.30 libdrm: local/libdrm 2.4.39-1 I've got similar lockup with kernel 3.6rc6 -- You are receiving this mail because: You are the assignee for the bug.

1 10

[PATCH -next v2] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()
by Wei Yongjun 11 Dec '12

11 Dec '12

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> In case of error, function arm_iommu_create_mapping() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c index 09db198..2482b7f 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c @@ -56,8 +56,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev) mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start, priv->da_space_size, priv->da_space_order); - if (!mapping) - return -ENOMEM; + if (IS_ERR(mapping)) + return PTR_ERR(mapping); dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);

2 1

[PATCH 1/2] drm: Make the HPD status updates debug logs more readable
by Damien Lespiau 10 Dec '12

10 Dec '12

From: Damien Lespiau <damien.lespiau(a)intel.com> Instead of just printing "status updated from 1 to 2", make those enum numbers immediately readable. v2: Also patch output_poll_execute() (Daniel Vetter) Signed-off-by: Damien Lespiau <damien.lespiau(a)intel.com> --- drivers/gpu/drm/drm_crtc_helper.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 1fe719f..524f0d3 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -950,6 +950,18 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev) } EXPORT_SYMBOL(drm_kms_helper_hotplug_event); +static const char *connector_status_str(enum drm_connector_status status) +{ + switch (status) { + case connector_status_connected: + return "connected"; + case connector_status_disconnected: + return "disconnected"; + default: + return "unknown"; + } +} + #define DRM_OUTPUT_POLL_PERIOD (10*HZ) static void output_poll_execute(struct work_struct *work) { @@ -984,10 +996,11 @@ static void output_poll_execute(struct work_struct *work) continue; connector->status = connector->funcs->detect(connector, false); - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to %d\n", + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s\n", connector->base.id, drm_get_connector_name(connector), - old_status, connector->status); + connector_status_str(old_status), + connector_status_str(connector->status)); if (old_status != connector->status) changed = true; } @@ -1062,10 +1075,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev) old_status = connector->status; connector->status = connector->funcs->detect(connector, false); - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to %d\n", + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s\n", connector->base.id, drm_get_connector_name(connector), - old_status, connector->status); + connector_status_str(old_status), + connector_status_str(connector->status)); if (old_status != connector->status) changed = true; } -- 1.7.11.7

2 2

[PATCH] drm: Make the HPD status updates debug logs more readable
by Damien Lespiau 10 Dec '12

10 Dec '12

From: Damien Lespiau <damien.lespiau(a)intel.com> Instead of just printing "status updated from 1 to 2", make those enum numbers immediately readable. Signed-off-by: Damien Lespiau <damien.lespiau(a)intel.com> --- drivers/gpu/drm/drm_crtc_helper.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 1fe719f..8b963fd 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -1043,6 +1043,18 @@ void drm_kms_helper_poll_fini(struct drm_device *dev) } EXPORT_SYMBOL(drm_kms_helper_poll_fini); +static const char *connector_status_str(enum drm_connector_status status) +{ + switch (status) { + case connector_status_connected: + return "connected"; + case connector_status_disconnected: + return "disconnected"; + default: + return "unknown"; + } +} + void drm_helper_hpd_irq_event(struct drm_device *dev) { struct drm_connector *connector; @@ -1062,10 +1074,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev) old_status = connector->status; connector->status = connector->funcs->detect(connector, false); - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to %d\n", + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s\n", connector->base.id, drm_get_connector_name(connector), - old_status, connector->status); + connector_status_str(old_status), + connector_status_str(connector->status)); if (old_status != connector->status) changed = true; } -- 1.7.11.7

3 2

[PATCH] drm/nouveau: fix takedown in move_notify
by Maarten Lankhorst 10 Dec '12

10 Dec '12

move_notify is called by ttm after the the object is idle and about to be destroyed. Clean up the vm list properly in that case. This is not a problem right now, since the list should already be empty, but if it wasn't empty, vm_put was not called which leads to random corruption later. With this fix, nouveau_gem_object_close can be safely changed to a noop, forcing the vm bindings to be removed when the original object is. This is not done in this patch since it may lead to the object staying mapped in the vm space until the gem object refcount drops to 0. This shouldn't be a big issue however. If we choose to do so does allow us to use ttm's delayed destruction mechanism to unmap vm after object is idle, resulting in ioread32 no longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma unmap in nouveau_gem_object_close. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 35ac57f..e8a47f0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) if (bo->destroy != nouveau_bo_del_ttm) return; + if (!new_mem) { + while (!list_empty(&nvbo->vma_list)) { + vma = list_first_entry(&nvbo->vma_list, struct nouveau_vma, head); + + nouveau_vm_unmap(vma); + nouveau_vm_put(vma); + list_del(&vma->head); + } + return; + } + list_for_each_entry(vma, &nvbo->vma_list, head) { - if (new_mem && new_mem->mem_type == TTM_PL_VRAM) { + if (new_mem->mem_type == TTM_PL_VRAM) { nouveau_vm_map(vma, new_mem->mm_node); - } else - if (new_mem && new_mem->mem_type == TTM_PL_TT && - nvbo->page_shift == vma->vm->vmm->spg_shift) { + } else if (new_mem->mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift) { if (((struct nouveau_mem *)new_mem->mm_node)->sg) nouveau_vm_map_sg_table(vma, 0, new_mem-> num_pages << PAGE_SHIFT, @@ -1153,8 +1163,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) nouveau_vm_map_sg(vma, 0, new_mem-> num_pages << PAGE_SHIFT, new_mem->mm_node); - } else { - nouveau_vm_unmap(vma); } } }

2 3

[Bug 26809] KMS/R200: Bad shading in NWN since Mesa rewrite
by bugzilla-daemon＠freedesktop.org 10 Dec '12

10 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=26809 Roland Scheidegger <sroland(a)vmware.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Roland Scheidegger <sroland(a)vmware.com> --- Ought to be fixed by 320d531373e7b0873f5de42f6173b986290f593f. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 10 Dec '12

10 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=22576 Roland Scheidegger <sroland(a)vmware.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #21 from Roland Scheidegger <sroland(a)vmware.com> --- (In reply to comment #18) > I think i've found source of these lighting problems on r200 in this and > other bugs. It is just a typo it seems in r200_state_init.c lit_emit() > > OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1); > > instead of OUT_VEC it needs to be OUT_SCL: > > OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1); Should be fixed by 320d531373e7b0873f5de42f6173b986290f593f, thanks! FWIW the command emit mechanism looks a bit too complicated it could profit from some refactoring. For instance it is still based on the fake drm_radeon_cmd_header_t structure, the scl vs. scl2 and vec vs. veclinear emits are nothing but crude hacks around limitations in that structure, even though since ums is gone there is absolutely no point in using that struct... Section size calcs are also somewhat confusing, the sanity code (which was really great back then) is totally unused etc. Maybe another day... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 10 Dec '12

10 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #20 from smoki <smoki00790(a)gmail.com> --- Yeah, i just see that, assume that it must be scl there then compared it with radeon state, there is setup just like that, but with correct vec/scl as i assume, so i changed it like that and that is it - tcl lighting works. Three year old typo - i deserve a medal ;). Someone could pushed it in git. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 10 Dec '12

10 Dec '12

https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #19 from Alan Swanson <swanson(a)ukfsn.org> --- This fixes lighting bug 26809 with NWN on my rv250, but R200 untested as yet. To correct the section size mismatch, add the following before the BEGIN_BATCH_NO_AUTOSTATE() line; dwords += 2; Thank you very much for finding this three year old radeon rewrite bug. I assume you discerned this from cmdscl used for LIT_CMD_1 versus cmdvec used for LIT_CMD_0? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 1/7] drm/nouveau: increase reservation sequence every retry
by Maarten Lankhorst 10 Dec '12

10 Dec '12

This is temporary until the fence framework can be used. With the lru/reservation atomicity removal it is possible to see your old sequence number and the buffer being reserved, leading to erroneously reporting -EDEADLK. Workaround it by bumping the sequence number every retry. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 7b9364b..f2bd59e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -322,8 +322,8 @@ validate_init(struct nouveau_channel *chan, struct drm_file *file_priv, int trycnt = 0; int ret, i; - sequence = atomic_add_return(1, &drm->ttm.validate_sequence); retry: + sequence = atomic_add_return(1, &drm->ttm.validate_sequence); if (++trycnt > 100000) { NV_ERROR(drm, "%s failed and gave up.\n", __func__); return -EINVAL; -- 1.8.0

1 6

← Newer
1
...
59
60
61
62
63
64
65
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2012