Re: Multiple issues with omapdrm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark <robdclark@xxxxxxxxx> wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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
>>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux