dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

[PATCH] drm/nouveau: fix lockdep splat in display
by Maarten Lankhorst 05 Feb '13

05 Feb '13

Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will be created. This removes the need of having multiple Fixes the following lockdep splat: ============================================= [ INFO: possible recursive locking detected ] 3.8.0-rc6-ninja+ #1 Not tainted --------------------------------------------- modprobe/585 is trying to acquire lock: (&subdev->mutex){+.+.+.}, at: [<ffffffffa016c323>] nouveau_instobj_create_+0x43/0x90 [nouveau] but task is already holding lock: (&subdev->mutex){+.+.+.}, at: [<ffffffffa017672d>] nv50_disp_data_ctor+0x5d/0xd0 [nouveau] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&subdev->mutex); lock(&subdev->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by modprobe/585: #0: (&__lockdep_no_validate__){......}, at: [<ffffffff813075f3>] __driver_attach+0x53/0xb0 #1: (&__lockdep_no_validate__){......}, at: [<ffffffff81307601>] __driver_attach+0x61/0xb0 #2: (drm_global_mutex){+.+.+.}, at: [<ffffffff812ee59c>] drm_get_pci_dev+0xbc/0x2b0 #3: (&subdev->mutex){+.+.+.}, at: [<ffffffffa017672d>] nv50_disp_data_ctor+0x5d/0xd0 [nouveau] stack backtrace: Pid: 585, comm: modprobe Not tainted 3.8.0-rc6-expert+ #1 Call Trace: [<ffffffff8108fde2>] validate_chain.isra.33+0xd72/0x10d0 [<ffffffff8105fa08>] ? __kernel_text_address+0x58/0x80 [<ffffffff8100575d>] ? print_context_stack+0x5d/0xd0 [<ffffffff81090bc1>] __lock_acquire+0x3a1/0xb60 [<ffffffff8108d504>] ? __lock_is_held+0x54/0x80 [<ffffffff8109184a>] lock_acquire+0x5a/0x70 [<ffffffffa016c323>] ? nouveau_instobj_create_+0x43/0x90 [nouveau] [<ffffffff81558739>] mutex_lock_nested+0x69/0x340 [<ffffffffa016c323>] ? nouveau_instobj_create_+0x43/0x90 [nouveau] [<ffffffffa0152370>] ? nouveau_object_create_+0x60/0xa0 [nouveau] [<ffffffffa016c323>] nouveau_instobj_create_+0x43/0x90 [nouveau] [<ffffffffa016cf8c>] nv50_instobj_ctor+0x4c/0xf0 [nouveau] [<ffffffffa0152163>] nouveau_object_ctor+0x33/0xc0 [nouveau] [<ffffffffa016cd51>] nv50_instmem_alloc+0x21/0x30 [nouveau] [<ffffffffa0150917>] nouveau_gpuobj_create_+0x247/0x2f0 [nouveau] [<ffffffff8155b35a>] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [<ffffffff810921fd>] ? trace_hardirqs_on_caller+0x10d/0x1a0 [<ffffffffa014f4bc>] nouveau_engctx_create_+0x25c/0x2a0 [nouveau] [<ffffffffa0176791>] nv50_disp_data_ctor+0xc1/0xd0 [nouveau] [<ffffffffa0153722>] ? nouveau_subdev_reset+0x52/0x60 [nouveau] [<ffffffffa0152163>] nouveau_object_ctor+0x33/0xc0 [nouveau] [<ffffffffa0152a42>] nouveau_object_new+0x112/0x240 [nouveau] [<ffffffffa01f4b1d>] nv50_display_create+0x18d/0x860 [nouveau] [<ffffffff8105cb5d>] ? __cancel_work_timer+0x6d/0xc0 [<ffffffffa01db8eb>] nouveau_display_create+0x3cb/0x670 [nouveau] [<ffffffffa01cb1bf>] nouveau_drm_load+0x26f/0x590 [nouveau] [<ffffffff81304c99>] ? device_register+0x19/0x20 [<ffffffff812efe91>] ? drm_sysfs_device_add+0x81/0xb0 [<ffffffff812ee65e>] drm_get_pci_dev+0x17e/0x2b0 [<ffffffff81245e56>] ? __pci_set_master+0x26/0x80 [<ffffffffa01cab2a>] nouveau_drm_probe+0x25a/0x2a0 [nouveau] [<ffffffff8124a386>] local_pci_probe+0x46/0x80 [<ffffffff8124ac11>] pci_device_probe+0x101/0x110 [<ffffffff813073d6>] driver_probe_device+0x76/0x240 [<ffffffff81307643>] __driver_attach+0xa3/0xb0 [<ffffffff813075a0>] ? driver_probe_device+0x240/0x240 [<ffffffff8130564d>] bus_for_each_dev+0x4d/0x90 [<ffffffff81306f39>] driver_attach+0x19/0x20 [<ffffffff81306af0>] bus_add_driver+0x1a0/0x270 [<ffffffffa023d000>] ? 0xffffffffa023cfff [<ffffffff81307cd2>] driver_register+0x72/0x170 [<ffffffffa023d000>] ? 0xffffffffa023cfff [<ffffffff8124ad0f>] __pci_register_driver+0x5f/0x70 [<ffffffff812ee8a5>] drm_pci_init+0x115/0x130 [<ffffffffa023d000>] ? 0xffffffffa023cfff [<ffffffffa023d000>] ? 0xffffffffa023cfff [<ffffffffa023d04d>] nouveau_drm_init+0x4d/0x1000 [nouveau] [<ffffffff810002da>] do_one_initcall+0x11a/0x170 [<ffffffff8109d044>] load_module+0xe84/0x1470 [<ffffffff81098c30>] ? in_lock_functions+0x20/0x20 [<ffffffff8122c22e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8109d6e7>] sys_init_module+0xb7/0xe0 [<ffffffff8155c156>] system_call_fastpath+0x1a/0x1f Reported-by: Arend van Spriel <arend(a)broadcom.com> Reported-by: Peter Hurley <peter(a)hurleysoftware.com> Reported-by: Daniel J Blueman <daniel(a)quora.org> Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- XXX: Add Cc: stable(a)kernel.org if it applies to 3.7 ? diff --git a/drivers/gpu/drm/nouveau/core/core/engctx.c b/drivers/gpu/drm/nouveau/core/core/engctx.c index 84c71fa..4a0ab2b 100644 --- a/drivers/gpu/drm/nouveau/core/core/engctx.c +++ b/drivers/gpu/drm/nouveau/core/core/engctx.c @@ -31,12 +31,15 @@ #include <subdev/vm.h> static inline int -nouveau_engctx_exists(struct nouveau_object *parent, +nouveau_engctx_exists(struct nouveau_object *parent, u32 flags, struct nouveau_engine *engine, void **pobject) { struct nouveau_engctx *engctx; struct nouveau_object *parctx; + if ((flags & NVOBJ_FLAG_CREAT_EXCL) && !list_empty(&engine->contexts)) + return -EBUSY; + list_for_each_entry(engctx, &engine->contexts, head) { parctx = nv_pclass(nv_object(engctx), NV_PARENT_CLASS); if (parctx == parent) { @@ -67,7 +70,7 @@ nouveau_engctx_create_(struct nouveau_object *parent, * and reference it instead of creating a new one */ spin_lock_irqsave(&engine->lock, save); - ret = nouveau_engctx_exists(parent, engine, pobject); + ret = nouveau_engctx_exists(parent, flags, engine, pobject); spin_unlock_irqrestore(&engine->lock, save); if (ret) return ret; @@ -94,7 +97,7 @@ nouveau_engctx_create_(struct nouveau_object *parent, * it's not possible to allocate the object with it held. */ spin_lock_irqsave(&engine->lock, save); - ret = nouveau_engctx_exists(parent, engine, pobject); + ret = nouveau_engctx_exists(parent, flags, engine, pobject); if (ret) { spin_unlock_irqrestore(&engine->lock, save); nouveau_object_ref(NULL, &engctx); diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index ca1a7d7..1d3dcd0 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c @@ -695,9 +695,8 @@ nv50_disp_data_ctor(struct nouveau_object *parent, struct nouveau_oclass *oclass, void *data, u32 size, struct nouveau_object **pobject) { - struct nv50_disp_priv *priv = (void *)engine; struct nouveau_engctx *ectx; - int ret = -EBUSY; + int ret; /* no context needed for channel objects... */ if (nv_mclass(parent) != NV_DEVICE_CLASS) { @@ -707,14 +706,10 @@ nv50_disp_data_ctor(struct nouveau_object *parent, } /* allocate display hardware to client */ - mutex_lock(&nv_subdev(priv)->mutex); - if (list_empty(&nv_engine(priv)->contexts)) { - ret = nouveau_engctx_create(parent, engine, oclass, NULL, - 0x10000, 0x10000, - NVOBJ_FLAG_HEAP, &ectx); - *pobject = nv_object(ectx); - } - mutex_unlock(&nv_subdev(priv)->mutex); + ret = nouveau_engctx_create(parent, engine, oclass, NULL, 0x10000, 0x10000, + NVOBJ_FLAG_HEAP | NVOBJ_FLAG_CREAT_EXCL, &ectx); + + *pobject = nv_object(ectx); return ret; } diff --git a/drivers/gpu/drm/nouveau/core/include/core/gpuobj.h b/drivers/gpu/drm/nouveau/core/include/core/gpuobj.h index b3b9ce4..9d47d51 100644 --- a/drivers/gpu/drm/nouveau/core/include/core/gpuobj.h +++ b/drivers/gpu/drm/nouveau/core/include/core/gpuobj.h @@ -12,6 +12,7 @@ struct nouveau_vm; #define NVOBJ_FLAG_ZERO_ALLOC 0x00000001 #define NVOBJ_FLAG_ZERO_FREE 0x00000002 #define NVOBJ_FLAG_HEAP 0x00000004 +#define NVOBJ_FLAG_CREAT_EXCL 0x00000008 struct nouveau_gpuobj { struct nouveau_object base;

1 0

[PATCH v4 0/1] Adds display-timing node parsing to exynos drm fimd
by Vikas Sajjan 05 Feb '13

05 Feb '13

This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v3: - addressed comments from Sean Paul <seanpaul(a)chromium.org>, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) changes since v1: - addressed comments from Sean Paul <seanpaul(a)chromium.org> Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41 +++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 4 deletions(-) -- 1.7.9.5

2 2

[Bug 60294] Flashplayer crashing
by bugzilla-daemon＠freedesktop.org 05 Feb '13

05 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=60294 Michel Dänzer <michel(a)daenzer.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mesa-dev(a)lists.freedesktop. |dri-devel(a)lists.freedesktop |org |.org Component|Other |Drivers/Gallium/r600 --- Comment #9 from Michel Dänzer <michel(a)daenzer.net> --- Does setting the environment variable R600_LLVM=0 or building Mesa without --enable-r600-llvm-compiler work around the problem? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 59672] New: Problems initializing Radeon driver: lockup during IB test
by bugzilla-daemon＠freedesktop.org 05 Feb '13

05 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=59672 Priority: medium Bug ID: 59672 Assignee: dri-devel(a)lists.freedesktop.org Summary: Problems initializing Radeon driver: lockup during IB test Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lucaskt(a)linux.vnet.ibm.com Hardware: PowerPC Status: NEW Version: XOrg 6.7.0 Component: DRM/Radeon Product: DRI Created attachment 73396 --> https://bugs.freedesktop.org/attachment.cgi?id=73396&action=edit modprobe radeon with drm.debug=1 Hi all, I've been trying to get a evergreen adapter to work with the Radeon driver on a ppc64 machine. And while attempting that, I'm running into what seems to be a infinite loop while running the IB test on ring 3. I'm using a 3.8.0-rc4 kernel from today. Follows an excerpt from the logs, the entire modprobe log can be found attached. [ 171.975487] [drm:evergreen_blit_init], evergreen blit allocated bo 00000600 vs 00000400 ps 00000500 [ 171.975631] radeon 0001:01:00.0: WB enabled [ 171.975636] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xc0000001d32b0c00 [ 171.975642] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xc0000001d32b0c0c [ 171.992732] [drm] ring test on 0 succeeded in 0 usecs [ 171.992799] [drm] ring test on 3 succeeded in 1 usecs [ 171.993112] [drm:evergreen_irq_set], evergreen_irq_set: sw int gfx [ 171.993154] [drm] ib test on ring 0 succeeded in 0 usecs [ 171.993197] [drm:evergreen_irq_set], r600_irq_set: sw int dma [ 172.419617] [drm:evergreen_irq_set], r600_irq_set: sw int dma .... [ 182.399612] [drm:evergreen_irq_set], r600_irq_set: sw int dma [ 182.409618] [drm:evergreen_irq_set], r600_irq_set: sw int dma [ 182.419604] radeon 0001:01:00.0: GPU lockup CP stall for more than 10000msec [ 182.419615] radeon 0001:01:00.0: GPU lockup (waiting for 0x0000000000000001 last fence id 0x0000000000000000) [ 182.419626] [drm:r600_dma_ib_test] *ERROR* radeon: fence wait failed (-35). [ 182.419634] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 3 (-35). Do you guys have any idea what could be wrong, or what should be looked into? Thanks -- You are receiving this mail because: You are the assignee for the bug.

1 14

[PATCH] drm/ttm: avoid allocation memory while spinlock is held v2
by j.glisse＠gmail.com 04 Feb '13

04 Feb '13

From: Jerome Glisse <jglisse(a)redhat.com> We need to take reference on the sync object while holding the fence spinlock but at the same time we don't want to allocate memory while holding the spinlock. This patch make sure we enforce both of this constraint. v2: actually test build it Fix https://bugzilla.redhat.com/show_bug.cgi?id=906296 Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 44420fc..f4b7acd 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -413,6 +413,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) * @bo: A pointer to a struct ttm_buffer_object. * @new_obj: A pointer to a pointer to a newly created ttm_buffer_object, * holding the data of @bo with the old placement. + * @sync_obj: the sync object caller is responsible to take a reference on + * behalf of this function * * This is a utility function that may be called after an accelerated move * has been scheduled. A new buffer object is created as a placeholder for @@ -423,11 +425,11 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) */ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, - struct ttm_buffer_object **new_obj) + struct ttm_buffer_object **new_obj, + void *sync_obj) { struct ttm_buffer_object *fbo; struct ttm_bo_device *bdev = bo->bdev; - struct ttm_bo_driver *driver = bdev->driver; fbo = kzalloc(sizeof(*fbo), GFP_KERNEL); if (!fbo) @@ -448,7 +450,8 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, fbo->vm_node = NULL; atomic_set(&fbo->cpu_writers, 0); - fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj); + /* reference on sync obj is taken by the caller of this function */ + fbo->sync_obj = sync_obj; kref_init(&fbo->list_kref); kref_init(&fbo->kref); fbo->destroy = &ttm_transfered_destroy; @@ -652,6 +655,8 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, } ttm_bo_free_old_node(bo); } else { + void *sync_obj; + /** * This should help pipeline ordinary buffer moves. * @@ -662,12 +667,14 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, set_bit(TTM_BO_PRIV_FLAG_MOVING, &bo->priv_flags); - /* ttm_buffer_object_transfer accesses bo->sync_obj */ - ret = ttm_buffer_object_transfer(bo, &ghost_obj); + /* take the ref on the sync object before releasing the spinlock */ + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); + if (tmp_obj) driver->sync_obj_unref(&tmp_obj); + ret = ttm_buffer_object_transfer(bo, &ghost_obj, sync_obj); if (ret) return ret; -- 1.7.10.4

3 3

re: drm/i915: Workaround to bump rc6 voltage to 450
by Dan Carpenter 04 Feb '13

04 Feb '13

Hi Ben, The patch 31643d54a739: "drm/i915: Workaround to bump rc6 voltage to 450" from Sep 26, 2012, leads to the following warning: "drivers/gpu/drm/i915/intel_pm.c:2662 gen6_enable_rps() warn: boolean comparison inside select" drivers/gpu/drm/i915/i915_reg.h 4260 #define GEN6_ENCODE_RC6_VID(mv) (((mv) / 5) - 245) < 0 ?: 0 ^^^^^^^^^^^^^^^^^^^^^^ It returns either 1 or 0 depending on if mv is >= 1230. 4261 #define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) > 0 ? ((vids) * 5) + 245 : 0) I think this is trying to reverse the other macro but the order of operations are wrong. It should be "(vids + 245) * 5". drivers/gpu/drm/i915/intel_pm.c 2654 rc6vids = 0; 2655 ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, &rc6vids); 2656 if (IS_GEN6(dev) && ret) { 2657 DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n"); 2658 } else if (IS_GEN6(dev) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff) < 450)) { 2659 DRM_DEBUG_DRIVER("You should update your BIOS. Correcting minimum rc6 voltage (%dmV->%dmV)\n", 2660 GEN6_DECODE_RC6_VID(rc6vids & 0xff), 450); 2661 rc6vids &= 0xffff00; 2662 rc6vids |= GEN6_ENCODE_RC6_VID(450); ^^^^^^^^^^^^^^^^^^^^^^^ This is the only caller and 450 is less than 1230 we store zero. 2663 ret = sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_RC6VIDS, rc6vids); 2664 if (ret) 2665 DRM_ERROR("Couldn't fix incorrect rc6 voltage\n"); 2666 } regards, dan carpenter

3 2

Radeon RV100 init fails with specific card+mobo - IRQ problem
by Meelis Roos 04 Feb '13

04 Feb '13

I have a test PC with AMD 760MPX chipset (Tyan S2466 Tiger MPX board) and Radeon RV100-based AGP card where radeon KMS modesetting does not work (does not work with any kernel tried so far (2.6.32, 3.2, 3.7, 3.8-rc6). >From dmesg with drm.debug=0xc [ 3.209617] agpgart-amdk7 0000:00:00.0: AMD 760MP chipset [ 3.325408] agpgart-amdk7 0000:00:00.0: AGP aperture is 512M @ 0xc0000000 [...] [ 3.529106] [drm] Initialized drm 1.1.0 20060810 [ 3.797715] [drm] radeon defaulting to kernel modesetting. [ 3.797817] [drm] radeon kernel modesetting enabled. [ 3.799108] [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1787:0x0F02). [ 3.799277] [drm] register mmio base: 0xB2000000 [ 3.799354] [drm] register mmio size: 65536 [ 3.799629] agpgart-amdk7 0000:00:00.0: AGP 2.0 bridge [ 3.799718] agpgart-amdk7 0000:00:00.0: putting AGP V2 device into 4x mode [ 3.799811] radeon 0000:01:05.0: putting AGP V2 device into 4x mode [ 3.799900] radeon 0000:01:05.0: GTT: 512M 0xC0000000 - 0xDFFFFFFF [ 3.799985] radeon 0000:01:05.0: VRAM: 128M 0x00000000E0000000 - 0x00000000E7FFFFFF (64M used) [ 3.800187] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.800268] [drm] Driver supports precise vblank timestamp query. [ 3.800350] radeon 0000:01:05.0: Fatal error during GPU init [ 3.800432] [drm] radeon: finishing device. [ 3.800509] [TTM] Memory type 2 has not been initialized [ 3.800590] [drm] radeon: cp finalized [ 3.800756] radeon: probe of 0000:01:05.0 failed with error -22 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller]) Subsystem: Hightech Information System Ltd. Device [1787:0f02] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B+ DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 2000 [size=256] Region 2: Memory at b2000000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at b2020000 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Adding some printks reveals it calls r100_init() -> radeon_irq_kms_init() -> drm_irq_install() -> drm_dev_to_irq() and that fails. So no IRQ, no KMS. lspci does not show Interrupt like on some other PCI devices. /proc/interrupts obviously does not contain the irq since we do not register any yet. There is no BIOS option of "Enable IRQ for VGA" or similar (BIOS is latest). Could this be the problem? What can I do to get KMS working on this computer? -- Meelis Roos (mroos(a)linux.ee)

3 6

[PATCH] drm/ttm: avoid allocation memory while spinlock is held
by j.glisse＠gmail.com 04 Feb '13

04 Feb '13

From: Jerome Glisse <jglisse(a)redhat.com> We need to take reference on the sync object while holding the fence spinlock but at the same time we don't want to allocate memory while holding the spinlock. This patch make sure we enforce both of this constraint. Fix https://bugzilla.redhat.com/show_bug.cgi?id=906296 Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 44420fc..77799a5 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -413,6 +413,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) * @bo: A pointer to a struct ttm_buffer_object. * @new_obj: A pointer to a pointer to a newly created ttm_buffer_object, * holding the data of @bo with the old placement. + * @sync_obj: the sync object caller is responsible to take a reference on + * behalf of this function * * This is a utility function that may be called after an accelerated move * has been scheduled. A new buffer object is created as a placeholder for @@ -423,7 +425,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) */ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, - struct ttm_buffer_object **new_obj) + struct ttm_buffer_object **new_obj, + void sync_obj) { struct ttm_buffer_object *fbo; struct ttm_bo_device *bdev = bo->bdev; @@ -448,7 +451,8 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, fbo->vm_node = NULL; atomic_set(&fbo->cpu_writers, 0); - fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj); + /* reference on sync obj is taken by the caller of this function */ + fbo->sync_obj = sync_obj; kref_init(&fbo->list_kref); kref_init(&fbo->kref); fbo->destroy = &ttm_transfered_destroy; @@ -652,6 +656,8 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, } ttm_bo_free_old_node(bo); } else { + void *sync_obj; + /** * This should help pipeline ordinary buffer moves. * @@ -662,12 +668,14 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, set_bit(TTM_BO_PRIV_FLAG_MOVING, &bo->priv_flags); - /* ttm_buffer_object_transfer accesses bo->sync_obj */ - ret = ttm_buffer_object_transfer(bo, &ghost_obj); + /* take the ref on the sync object before releasing the spinlock */ + sync_obj = driver->sync_obj_ref(bo->sync_obj); spin_unlock(&bdev->fence_lock); + if (tmp_obj) driver->sync_obj_unref(&tmp_obj); + ret = ttm_buffer_object_transfer(bo, &ghost_obj, sync_obj); if (ret) return ret; -- 1.7.10.4

1 0

status of [Patch] drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try ?
by Jerry Snitselaar 04 Feb '13

04 Feb '13

What is the current status of this patch? I haven't seen it show up in -next or linus's tree. Jerry

1 0

DMAR faults from unrelated device when vfio is used
by David Gstir 04 Feb '13

04 Feb '13

Hi! I get the following error messages over and over again when using vfio in qemu-kvm: [ 1692.021403] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr 1a45aa9000 [ 1692.021403] DMAR:[fault reason 12] non-zero reserved fields in PTE [ 1692.021416] dmar: DRHD: handling fault status reg 2 This pci device is the graphics card, which I did not assign to qemu! I did assign the following devices: 00:1a.0, 00:1b.0, 00:1c.0, 00:1c.6, 00:1d.0, 03:00.0. The error occurs at random and is not reproducible every time. It happens about every third reboot. I'm running qemu-kvm 1.3.0 (kvm-1.3.0-187.3), kernel 3.8.0-rc5 and windows 7 as guest OS. The hardware uses an Intel IOMMU. See attachments for output of lspci, and details on iommu groups I'm not sure if this problem originates from qemu, kvm, vfio or the GPU driver. Do you have any hints how to debug this further? Thanks, David PS: please cc me, I'm not subscribed.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013