Multiple issues with omapdrm
Rob Clark
robdclark at gmail.com
Wed Jun 5 03:57:05 PDT 2013
On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I encountered.
>> For most of them I don't have any idea where to even start looking for a problem,
>> so I hope that you may have some ideas.
>>
>>
>> dispc_runtime_get/put used in irq context
>> =========================================
>>
>> dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
>> around that with if (!in_atomic()), but I have no idea yet how to fix
>> it properly.
>
> Probably should have a flag/refcnt that is set when in the irq hander,
> since we know that things are on in irq.
>
>>
>> drm_crtc warning
>> ================
>>
>> I got this once when unloading the modules, but haven't happened since:
>>
>> drm_crtc.c line 3869
>>
>> WARN_ON(!list_empty(&dev->mode_config.fb_list));
>>
>> As it only happened once, maybe some kind of race.
>>
>
> Hmm, this is new.. it is certain that there can be a fb with a
> reference still around, waiting for a vblank/framedone. But I think
> it should already be removed from userspace perspective and no longer
> on fb_list. I think I need to go back and have a closer look at
> 2b677e8c0 where Daniel introduced that WARN_ON().
>
>> omap_gem warning
>> ================
>>
>> This happens on module unload:
>
> oh, that is easy.. it is because the omap_fbdev.c does an unbalanced
> omap_gem_get_paddr() to keep the fbcon fb from getting unmapped from
> tiler (so if we have to restore fbcon mode in an opps, we don't have
> to worry about grabbing mutexes or anything like that). Maybe
> somewhere in the cleanup it should do a put_paddr(). Otoh, I have
> some skepticism about whether module unloading is really going to be
> that reliable in practice, so meh..
>
by which I mean: module unloading is a nice-to-have for development,
but not a real use case.. it is more important to fix the issues we
have with module loading:
1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
need to rename the .ko
2) sorting out the modprobe of panel drivers.. although with the
current structure of omapdrm+omapdss I can't think of any clean way to
handle this. I suppose we could do a hack with a bunch of
request_module()s
these are issues that actually cause problems for distros which want
to build a unified kernel with all the drm drivers as modules
BR,
-R
>
> BR,
> -R
>
>>
>> [ 30.167480] ------------[ cut here ]------------
>> [ 30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 omap_gem_free_object+0x24c/0x25c [omapdrm]()
>> [ 30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal panel_tfp410 panel_generic_dpi omapdss
>> [ 30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.10.0-rc1-00004-g8ed4760 #110
>> [ 30.183166] Workqueue: omapdrm apply_worker [omapdrm]
>> [ 30.207641] Backtrace:
>> [ 30.210296] [<c00189ac>] (dump_backtrace+0x0/0x10c) from [<c0018b48>] (show_stack+0x18/0x1c)
>> [ 30.219299] r6:bf0e5988 r5:00000009 r4:00000000 r3:eb872080
>> [ 30.225433] [<c0018b30>] (show_stack+0x0/0x1c) from [<c0520c04>] (dump_stack+0x20/0x28)
>> [ 30.234039] [<c0520be4>] (dump_stack+0x0/0x28) from [<c0041fb8>] (warn_slowpath_common+0x54/0x74)
>> [ 30.243530] [<c0041f64>] (warn_slowpath_common+0x0/0x74) from [<c0041ffc>] (warn_slowpath_null+0x24/0x2c)
>> [ 30.243774] r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
>> r3:00000009
>> [ 30.262176] [<c0041fd8>] (warn_slowpath_null+0x0/0x2c) from [<bf0e5988>] (omap_gem_free_object+0x24c/0x25c [omapdrm])
>> [ 30.273498] [<bf0e573c>] (omap_gem_free_object+0x0/0x25c [omapdrm]) from [<bf080c0c>] (drm_gem_object_free+0x30/0x38 [drm])
>> [ 30.285675] [<bf080bdc>] (drm_gem_object_free+0x0/0x38 [drm]) from [<bf0e196c>] (omap_plane_post_apply+0x108/0x10c [omapdrm])
>> [ 30.285675] [<bf0e1864>] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from [<bf0e100c>] (apply_worker+0x68/0x188 [omapdrm])
>> [ 30.309509] r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
>> [ 30.312042] [<bf0e0fa4>] (apply_worker+0x0/0x188 [omapdrm]) from [<c005ef10>] (process_one_work+0x1b8/0x4e8)
>> [ 30.325012] [<c005ed58>] (process_one_work+0x0/0x4e8) from [<c005f654>] (worker_thread+0x138/0x388)
>> [ 30.325378] [<c005f51c>] (worker_thread+0x0/0x388) from [<c0066070>] (kthread+0xac/0xb8)
>> [ 30.343292] [<c0065fc4>] (kthread+0x0/0xb8) from [<c00146e8>] (ret_from_fork+0x14/0x2c)
>> [ 30.351837] r7:00000000 r6:00000000 r5:c0065fc4 r4:eb843d54
>> [ 30.352111] ---[ end trace 78317663d3b4807c ]---
>>
>>
>> Deadlock at module unload
>> =========================
>> When removing the modules, there's a dealock. This is the last line printed:
>>
>> [ 30.399200] [drm] Module unloaded
>>
>> Then, when the deadlock detection kicks in:
>>
>> [ 240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
>> [ 240.962432] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [ 240.977508] rmmod D c0524964 0 894 884 0x00000000
>> [ 240.981719] Backtrace:
>> [ 240.987274] [<c05245ec>] (__schedule+0x0/0x7e8) from [<c0524eb0>] (schedule+0x38/0x78)
>> [ 240.995819] [<c0524e78>] (schedule+0x0/0x78) from [<c05251ac>] (schedule_preempt_disabled+0x28/0x38)
>> [ 241.005706] [<c0525184>] (schedule_preempt_disabled+0x0/0x38) from [<c05238c4>] (mutex_lock_nested+0x1b8/0x3a8)
>> [ 241.016693] r4:c07f5bf8 r3:eb978180
>> [ 241.020812] [<c052370c>] (mutex_lock_nested+0x0/0x3a8) from [<c033c9d0>] (driver_detach+0x4c/0xc0)
>> [ 241.021026] [<c033c984>] (driver_detach+0x0/0xc0) from [<c033bd24>] (bus_remove_driver+0x94/0xfc)
>> [ 241.040100] r6:c07f5b38 r5:bf0ec410 r4:00000000 r3:00000000
>> [ 241.042633] [<c033bc90>] (bus_remove_driver+0x0/0xfc) from [<c033d054>] (driver_unregister+0x58/0x78)
>> [ 241.056060] r6:c07c28a4 r5:bf0ec410 r4:00000000 r3:eb978180
>> [ 241.062164] [<c033cffc>] (driver_unregister+0x0/0x78) from [<c033ddc0>] (platform_driver_unregister+0x14/0x18)
>> [ 241.072875] r5:bf0ebc18 r4:c07c2860
>> [ 241.075439] [<c033ddac>] (platform_driver_unregister+0x0/0x18) from [<bf0df2c8>] (pdev_remove+0x48/0x54 [omapdrm])
>> [ 241.087921] [<bf0df280>] (pdev_remove+0x0/0x54 [omapdrm]) from [<c033dc38>] (platform_drv_remove+0x20/0x24)
>> [ 241.098327] r4:c07c2870 r3:bf0df280
>> [ 241.100860] [<c033dc18>] (platform_drv_remove+0x0/0x24) from [<c033bfc4>] (__device_release_driver+0x78/0xd4)
>> [ 241.112792] [<c033bf4c>] (__device_release_driver+0x0/0xd4) from [<c033ca40>] (driver_detach+0xbc/0xc0)
>> [ 241.113159] r5:bf0ebc18 r4:c07c2870
>> [ 241.122833] [<c033c984>] (driver_detach+0x0/0xc0) from [<c033bd24>] (bus_remove_driver+0x94/0xfc)
>> [ 241.136108] r6:c07f5b38 r5:bf0ebc18 r4:00000000 r3:00000000
>> [ 241.142211] [<c033bc90>] (bus_remove_driver+0x0/0xfc) from [<c033d054>] (driver_unregister+0x58/0x78)
>> [ 241.152069] r6:00000880 r5:bf0ebc18 r4:00000000 r3:00000000
>> [ 241.153472] [<c033cffc>] (driver_unregister+0x0/0x78) from [<c033ddc0>] (platform_driver_unregister+0x14/0x18)
>> [ 241.168823] r5:bf0ec4a0 r4:00000000
>> [ 241.171356] [<c033ddac>] (platform_driver_unregister+0x0/0x18) from [<bf0e9bb8>] (omap_drm_fini+0x28/0x3c [omapdrm])
>> [ 241.183990] [<bf0e9b90>] (omap_drm_fini+0x0/0x3c [omapdrm]) from [<c009ef10>] (SyS_delete_module+0x154/0x288)
>> [ 241.194610] [<c009edbc>] (SyS_delete_module+0x0/0x288) from [<c0014620>] (ret_fast_syscall+0x0/0x48)
>> [ 241.204345] r7:00000081 r6:006d7264 r5:70616d6f r4:0001aac4
>> [ 241.206726] 3 locks held by rmmod/894:
>> [ 241.214416] #0: (&__lockdep_no_validate__){......}, at: [<c033c9d0>] driver_detach+0x4c/0xc0
>> [ 241.223693] #1: (&__lockdep_no_validate__){......}, at: [<c033c9dc>] driver_detach+0x58/0xc0
>> [ 241.232940] #2: (&__lockdep_no_validate__){......}, at: [<c033c9d0>] driver_detach+0x4c/0xc0
>>
>> Tomi
>>
More information about the dri-devel
mailing list