* Odroid U3 mutex deadlock.
@ 2015-12-12 4:32 Anand Moon
[not found] ` <CAE-5t2stNAGnHSW1RG9Ek8Zas6c3wgdULYP9sFRw=9LyLz+rLA@mail.gmail.com>
2015-12-13 23:45 ` Krzysztof Kozlowski
0 siblings, 2 replies; 5+ messages in thread
From: Anand Moon @ 2015-12-12 4:32 UTC (permalink / raw)
To: Krzysztof Kozłowski, linux-samsung-soc
Cc: Linux Kernel, Javier Martinez Canillas, Kukjin Kim, linux-arm-kernel
Hi Krzysztof,
I am just observing this deadlock om my Odroid U3.
------------------------------------------------------------------------------------------------------------------
[ 2.937531] =============================================
[ 2.938733] [ INFO: possible recursive locking detected ]
[ 2.944117] 4.4.0-rc4-xu3s #32 Not tainted
[ 2.948195] ---------------------------------------------
[ 2.953577] swapper/0/1 is trying to acquire lock:
[ 2.958351] (&genpd->lock){+.+...}, at: [<c0361550>]
__genpd_poweron+0x64/0x108
[ 2.965727]
[ 2.965727] but task is already holding lock:
[ 2.971543] (&genpd->lock){+.+...}, at: [<c0361af8>]
genpd_dev_pm_attach+0x168/0x1b8
[ 2.979355]
[ 2.979355] other info that might help us debug this:
[ 2.985865] Possible unsafe locking scenario:
[ 2.985865]
[ 2.991768] CPU0
[ 2.994198] ----
[ 2.996628] lock(&genpd->lock);
[ 2.999926] lock(&genpd->lock);
[ 3.003225]
[ 3.003225] *** DEADLOCK ***
[ 3.003225]
[ 3.009128] May be due to missing lock nesting notation
[ 3.009128]
[ 3.015900] 3 locks held by swapper/0/1:
[ 3.019804] #0: (&dev->mutex){......}, at: [<c0350910>]
__driver_attach+0x48/0x98
[ 3.027442] #1: (&dev->mutex){......}, at: [<c0350920>]
__driver_attach+0x58/0x98
[ 3.035081] #2: (&genpd->lock){+.+...}, at: [<c0361af8>]
genpd_dev_pm_attach+0x168/0x1b8
[ 3.043326]
[ 3.043326] stack backtrace:
[ 3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
[ 3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 3.060444] [<c0016c98>] (unwind_backtrace) from [<c00139c4>]
(show_stack+0x10/0x14)
[ 3.068163] [<c00139c4>] (show_stack) from [<c0270df0>]
(dump_stack+0x84/0xc4)
[ 3.075367] [<c0270df0>] (dump_stack) from [<c00780b8>]
(__lock_acquire+0x1f88/0x215c)
[ 3.083262] [<c00780b8>] (__lock_acquire) from [<c007886c>]
(lock_acquire+0xa4/0xd0)
[ 3.090990] [<c007886c>] (lock_acquire) from [<c0641f2c>]
(mutex_lock_nested+0x70/0x4d4)
[ 3.099061] [<c0641f2c>] (mutex_lock_nested) from [<c0361550>]
(__genpd_poweron+0x64/0x108)
[ 3.107393] [<c0361550>] (__genpd_poweron) from [<c0361b00>]
(genpd_dev_pm_attach+0x170/0x1b8)
[ 3.115986] [<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>]
(platform_drv_probe+0x2c/0xac)
[ 3.124667] [<c03520a8>] (platform_drv_probe) from [<c03507d4>]
(driver_probe_device+0x208/0x2fc)
[ 3.133519] [<c03507d4>] (driver_probe_device) from [<c035095c>]
(__driver_attach+0x94/0x98)
[ 3.141939] [<c035095c>] (__driver_attach) from [<c034ec14>]
(bus_for_each_dev+0x68/0x9c)
[ 3.150097] [<c034ec14>] (bus_for_each_dev) from [<c034fec8>]
(bus_add_driver+0x1a0/0x218)
[ 3.158344] [<c034fec8>] (bus_add_driver) from [<c035115c>]
(driver_register+0x78/0xf8)
[ 3.166330] [<c035115c>] (driver_register) from [<c0338488>]
(exynos_drm_register_drivers+0x28/0x74)
[ 3.175441] [<c0338488>] (exynos_drm_register_drivers) from
[<c0338594>] (exynos_drm_init+0x6c/0xc4)
[ 3.184556] [<c0338594>] (exynos_drm_init) from [<c00097f4>]
(do_one_initcall+0x90/0x1dc)
[ 3.192718] [<c00097f4>] (do_one_initcall) from [<c0895e08>]
(kernel_init_freeable+0x158/0x1f8)
[ 3.201396] [<c0895e08>] (kernel_init_freeable) from [<c063ecac>]
(kernel_init+0x8/0xe8)
[ 3.209469] [<c063ecac>] (kernel_init) from [<c000f7d0>]
(ret_from_fork+0x14/0x24)
[ 3.217932] exynos-hdmi 12d00000.hdmi: GPIO lookup for consumer hpd
[ 3.223293] exynos-hdmi 12d00000.hdmi: using device tree for GPIO lookup
[ 3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
property of node '/hdmi@12D00000[0]'
[ 3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
node '/hdmi@12D00000[0]' - status (0)
[ 3.253430] exynos-drm exynos-drm: bound 12c10000.mixer (ops
mixer_component_ops)
[ 3.256216] exynos-drm exynos-drm: bound 12d00000.hdmi (ops
hdmi_component_ops)
[ 3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.269812] [drm] No driver support for vblank timestamp query.
[ 3.323251] exynos-drm exynos-drm: fb0: frame buffer device
[ 3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
-----------------------------------------------------------------------------------------------------------------------
-Anand Moon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Odroid U3 mutex deadlock.
[not found] ` <CAE-5t2stNAGnHSW1RG9Ek8Zas6c3wgdULYP9sFRw=9LyLz+rLA@mail.gmail.com>
@ 2015-12-13 2:36 ` Anand Moon
0 siblings, 0 replies; 5+ messages in thread
From: Anand Moon @ 2015-12-13 2:36 UTC (permalink / raw)
To: Thomas Pietrowski
Cc: Krzysztof Kozlowski, linux-samsung-soc, Javier Martinez Canillas,
linux-arm-kernel, Kukjin Kim, Linux Kernel
Hi Thomas,
On 12 December 2015 at 16:58, Thomas Pietrowski <thopiekar@gmail.com> wrote:
> I'm also using 4.4.0-rc4 here on my U3+. And so far it is working well. I
> just had a freeze yesterday, but I didn't had the UART connected, so
> couldn't catch the reason. The curious thing was that the heartbeat LED was
> still blinking, but USB keyboard and Ethernet/SSH (but LEDs still on) were
> not working.
>
> Could you upload your .config? Maybe it could be useful for others :)
>
> Regards
>
> Am 12.12.2015 05:33 schrieb "Anand Moon" <linux.amoon@gmail.com>:
>>
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>>
>> ------------------------------------------------------------------------------------------------------------------
>>
>> [ 2.937531] =============================================
>> [ 2.938733] [ INFO: possible recursive locking detected ]
>> [ 2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [ 2.948195] ---------------------------------------------
>> [ 2.953577] swapper/0/1 is trying to acquire lock:
>> [ 2.958351] (&genpd->lock){+.+...}, at: [<c0361550>]
>> __genpd_poweron+0x64/0x108
>> [ 2.965727]
>> [ 2.965727] but task is already holding lock:
>> [ 2.971543] (&genpd->lock){+.+...}, at: [<c0361af8>]
>> genpd_dev_pm_attach+0x168/0x1b8
>> [ 2.979355]
>> [ 2.979355] other info that might help us debug this:
>> [ 2.985865] Possible unsafe locking scenario:
>> [ 2.985865]
>> [ 2.991768] CPU0
>> [ 2.994198] ----
>> [ 2.996628] lock(&genpd->lock);
>> [ 2.999926] lock(&genpd->lock);
>> [ 3.003225]
>> [ 3.003225] *** DEADLOCK ***
>> [ 3.003225]
>> [ 3.009128] May be due to missing lock nesting notation
>> [ 3.009128]
>> [ 3.015900] 3 locks held by swapper/0/1:
>> [ 3.019804] #0: (&dev->mutex){......}, at: [<c0350910>]
>> __driver_attach+0x48/0x98
>> [ 3.027442] #1: (&dev->mutex){......}, at: [<c0350920>]
>> __driver_attach+0x58/0x98
>> [ 3.035081] #2: (&genpd->lock){+.+...}, at: [<c0361af8>]
>> genpd_dev_pm_attach+0x168/0x1b8
>> [ 3.043326]
>> [ 3.043326] stack backtrace:
>> [ 3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s
>> #32
>> [ 3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 3.060444] [<c0016c98>] (unwind_backtrace) from [<c00139c4>]
>> (show_stack+0x10/0x14)
>> [ 3.068163] [<c00139c4>] (show_stack) from [<c0270df0>]
>> (dump_stack+0x84/0xc4)
>> [ 3.075367] [<c0270df0>] (dump_stack) from [<c00780b8>]
>> (__lock_acquire+0x1f88/0x215c)
>> [ 3.083262] [<c00780b8>] (__lock_acquire) from [<c007886c>]
>> (lock_acquire+0xa4/0xd0)
>> [ 3.090990] [<c007886c>] (lock_acquire) from [<c0641f2c>]
>> (mutex_lock_nested+0x70/0x4d4)
>> [ 3.099061] [<c0641f2c>] (mutex_lock_nested) from [<c0361550>]
>> (__genpd_poweron+0x64/0x108)
>> [ 3.107393] [<c0361550>] (__genpd_poweron) from [<c0361b00>]
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [ 3.115986] [<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>]
>> (platform_drv_probe+0x2c/0xac)
>> [ 3.124667] [<c03520a8>] (platform_drv_probe) from [<c03507d4>]
>> (driver_probe_device+0x208/0x2fc)
>> [ 3.133519] [<c03507d4>] (driver_probe_device) from [<c035095c>]
>> (__driver_attach+0x94/0x98)
>> [ 3.141939] [<c035095c>] (__driver_attach) from [<c034ec14>]
>> (bus_for_each_dev+0x68/0x9c)
>> [ 3.150097] [<c034ec14>] (bus_for_each_dev) from [<c034fec8>]
>> (bus_add_driver+0x1a0/0x218)
>> [ 3.158344] [<c034fec8>] (bus_add_driver) from [<c035115c>]
>> (driver_register+0x78/0xf8)
>> [ 3.166330] [<c035115c>] (driver_register) from [<c0338488>]
>> (exynos_drm_register_drivers+0x28/0x74)
>> [ 3.175441] [<c0338488>] (exynos_drm_register_drivers) from
>> [<c0338594>] (exynos_drm_init+0x6c/0xc4)
>> [ 3.184556] [<c0338594>] (exynos_drm_init) from [<c00097f4>]
>> (do_one_initcall+0x90/0x1dc)
>> [ 3.192718] [<c00097f4>] (do_one_initcall) from [<c0895e08>]
>> (kernel_init_freeable+0x158/0x1f8)
>> [ 3.201396] [<c0895e08>] (kernel_init_freeable) from [<c063ecac>]
>> (kernel_init+0x8/0xe8)
>> [ 3.209469] [<c063ecac>] (kernel_init) from [<c000f7d0>]
>> (ret_from_fork+0x14/0x24)
>> [ 3.217932] exynos-hdmi 12d00000.hdmi: GPIO lookup for consumer hpd
>> [ 3.223293] exynos-hdmi 12d00000.hdmi: using device tree for GPIO
>> lookup
>> [ 3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
>> property of node '/hdmi@12D00000[0]'
>> [ 3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
>> node '/hdmi@12D00000[0]' - status (0)
>> [ 3.253430] exynos-drm exynos-drm: bound 12c10000.mixer (ops
>> mixer_component_ops)
>> [ 3.256216] exynos-drm exynos-drm: bound 12d00000.hdmi (ops
>> hdmi_component_ops)
>> [ 3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 3.269812] [drm] No driver support for vblank timestamp query.
>> [ 3.323251] exynos-drm exynos-drm: fb0: frame buffer device
>> [ 3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>
>>
>> -----------------------------------------------------------------------------------------------------------------------
>> -Anand Moon
I just using exynos_defconfig + kernel hacking flags.
diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index e0841a5..402a37f 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
@@ -100,10 +101,8 @@ CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_NTC_THERMISTOR=y
CONFIG_SENSORS_PWM_FAN=y
CONFIG_SENSORS_INA2XX=y
-CONFIG_THERMAL=y
CONFIG_CPU_THERMAL=y
CONFIG_THERMAL_EMULATION=y
-CONFIG_EXYNOS_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MFD_CROS_EC=y
@@ -132,8 +131,6 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_DRM=y
-CONFIG_DRM_NXP_PTN3460=y
-CONFIG_DRM_PARADE_PS8622=y
CONFIG_DRM_EXYNOS=y
CONFIG_DRM_EXYNOS_FIMD=y
CONFIG_DRM_EXYNOS_DSI=y
@@ -141,6 +138,8 @@ CONFIG_DRM_EXYNOS_MIXER=y
CONFIG_DRM_EXYNOS_HDMI=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
+CONFIG_DRM_NXP_PTN3460=y
+CONFIG_DRM_PARADE_PS8622=y
CONFIG_EXYNOS_VIDEO=y
CONFIG_EXYNOS_MIPI_DSI=y
CONFIG_LCD_CLASS_DEVICE=y
@@ -219,10 +218,36 @@ CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_PAGEALLOC=y
+CONFIG_DEBUG_OBJECTS=y
+CONFIG_DEBUG_OBJECTS_SELFTEST=y
+CONFIG_DEBUG_OBJECTS_FREE=y
+CONFIG_DEBUG_OBJECTS_TIMERS=y
+CONFIG_DEBUG_OBJECTS_WORK=y
+CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
+CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
+CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
+CONFIG_SCHEDSTATS=y
+CONFIG_SCHED_STACK_END_CHECK=y
+CONFIG_TIMER_STATS=y
CONFIG_DEBUG_RT_MUTEXES=y
-CONFIG_DEBUG_SPINLOCK=y
-CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_LOCK_STAT=y
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_DEBUG_ATOMIC_SLEEP=y
+CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
+CONFIG_LOCK_TORTURE_TEST=m
+CONFIG_DEBUG_PI_LIST=y
+CONFIG_DEBUG_SG=y
+CONFIG_DEBUG_NOTIFIERS=y
+CONFIG_DEBUG_CREDENTIALS=y
+CONFIG_PROVE_RCU_REPEATEDLY=y
+CONFIG_SPARSE_RCU_POINTER=y
+CONFIG_RCU_TORTURE_TEST=m
+CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT=y
+CONFIG_RCU_TRACE=y
CONFIG_DEBUG_USER=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRC_CCITT=y
-Anand Moon
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Odroid U3 mutex deadlock.
2015-12-12 4:32 Odroid U3 mutex deadlock Anand Moon
[not found] ` <CAE-5t2stNAGnHSW1RG9Ek8Zas6c3wgdULYP9sFRw=9LyLz+rLA@mail.gmail.com>
@ 2015-12-13 23:45 ` Krzysztof Kozlowski
2016-01-02 5:14 ` Anand Moon
1 sibling, 1 reply; 5+ messages in thread
From: Krzysztof Kozlowski @ 2015-12-13 23:45 UTC (permalink / raw)
To: Anand Moon, linux-samsung-soc
Cc: Linux Kernel, Javier Martinez Canillas, Kukjin Kim, linux-arm-kernel
On 12.12.2015 13:32, Anand Moon wrote:
> Hi Krzysztof,
>
> I am just observing this deadlock om my Odroid U3.
This is not a deadlock yet, just a report from lockdep. Could be a real
issue, could be false positive, maybe some locks miss nesting annotations.
Typical information for bug report would be useful, like the exact
version (it is mentioned in lockdep report but is it really correct?)
and reproducibility. And of course git-bisect would be nice to have, see:
Documentation/BUG-HUNTING
Best regards,
Krzysztof
> ------------------------------------------------------------------------------------------------------------------
>
> [ 2.937531] =============================================
> [ 2.938733] [ INFO: possible recursive locking detected ]
> [ 2.944117] 4.4.0-rc4-xu3s #32 Not tainted
> [ 2.948195] ---------------------------------------------
> [ 2.953577] swapper/0/1 is trying to acquire lock:
> [ 2.958351] (&genpd->lock){+.+...}, at: [<c0361550>]
> __genpd_poweron+0x64/0x108
> [ 2.965727]
> [ 2.965727] but task is already holding lock:
> [ 2.971543] (&genpd->lock){+.+...}, at: [<c0361af8>]
> genpd_dev_pm_attach+0x168/0x1b8
> [ 2.979355]
> [ 2.979355] other info that might help us debug this:
> [ 2.985865] Possible unsafe locking scenario:
> [ 2.985865]
> [ 2.991768] CPU0
> [ 2.994198] ----
> [ 2.996628] lock(&genpd->lock);
> [ 2.999926] lock(&genpd->lock);
> [ 3.003225]
> [ 3.003225] *** DEADLOCK ***
> [ 3.003225]
> [ 3.009128] May be due to missing lock nesting notation
> [ 3.009128]
> [ 3.015900] 3 locks held by swapper/0/1:
> [ 3.019804] #0: (&dev->mutex){......}, at: [<c0350910>]
> __driver_attach+0x48/0x98
> [ 3.027442] #1: (&dev->mutex){......}, at: [<c0350920>]
> __driver_attach+0x58/0x98
> [ 3.035081] #2: (&genpd->lock){+.+...}, at: [<c0361af8>]
> genpd_dev_pm_attach+0x168/0x1b8
> [ 3.043326]
> [ 3.043326] stack backtrace:
> [ 3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
> [ 3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 3.060444] [<c0016c98>] (unwind_backtrace) from [<c00139c4>]
> (show_stack+0x10/0x14)
> [ 3.068163] [<c00139c4>] (show_stack) from [<c0270df0>]
> (dump_stack+0x84/0xc4)
> [ 3.075367] [<c0270df0>] (dump_stack) from [<c00780b8>]
> (__lock_acquire+0x1f88/0x215c)
> [ 3.083262] [<c00780b8>] (__lock_acquire) from [<c007886c>]
> (lock_acquire+0xa4/0xd0)
> [ 3.090990] [<c007886c>] (lock_acquire) from [<c0641f2c>]
> (mutex_lock_nested+0x70/0x4d4)
> [ 3.099061] [<c0641f2c>] (mutex_lock_nested) from [<c0361550>]
> (__genpd_poweron+0x64/0x108)
> [ 3.107393] [<c0361550>] (__genpd_poweron) from [<c0361b00>]
> (genpd_dev_pm_attach+0x170/0x1b8)
> [ 3.115986] [<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>]
> (platform_drv_probe+0x2c/0xac)
> [ 3.124667] [<c03520a8>] (platform_drv_probe) from [<c03507d4>]
> (driver_probe_device+0x208/0x2fc)
> [ 3.133519] [<c03507d4>] (driver_probe_device) from [<c035095c>]
> (__driver_attach+0x94/0x98)
> [ 3.141939] [<c035095c>] (__driver_attach) from [<c034ec14>]
> (bus_for_each_dev+0x68/0x9c)
> [ 3.150097] [<c034ec14>] (bus_for_each_dev) from [<c034fec8>]
> (bus_add_driver+0x1a0/0x218)
> [ 3.158344] [<c034fec8>] (bus_add_driver) from [<c035115c>]
> (driver_register+0x78/0xf8)
> [ 3.166330] [<c035115c>] (driver_register) from [<c0338488>]
> (exynos_drm_register_drivers+0x28/0x74)
> [ 3.175441] [<c0338488>] (exynos_drm_register_drivers) from
> [<c0338594>] (exynos_drm_init+0x6c/0xc4)
> [ 3.184556] [<c0338594>] (exynos_drm_init) from [<c00097f4>]
> (do_one_initcall+0x90/0x1dc)
> [ 3.192718] [<c00097f4>] (do_one_initcall) from [<c0895e08>]
> (kernel_init_freeable+0x158/0x1f8)
> [ 3.201396] [<c0895e08>] (kernel_init_freeable) from [<c063ecac>]
> (kernel_init+0x8/0xe8)
> [ 3.209469] [<c063ecac>] (kernel_init) from [<c000f7d0>]
> (ret_from_fork+0x14/0x24)
> [ 3.217932] exynos-hdmi 12d00000.hdmi: GPIO lookup for consumer hpd
> [ 3.223293] exynos-hdmi 12d00000.hdmi: using device tree for GPIO lookup
> [ 3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
> property of node '/hdmi@12D00000[0]'
> [ 3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
> node '/hdmi@12D00000[0]' - status (0)
> [ 3.253430] exynos-drm exynos-drm: bound 12c10000.mixer (ops
> mixer_component_ops)
> [ 3.256216] exynos-drm exynos-drm: bound 12d00000.hdmi (ops
> hdmi_component_ops)
> [ 3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 3.269812] [drm] No driver support for vblank timestamp query.
> [ 3.323251] exynos-drm exynos-drm: fb0: frame buffer device
> [ 3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> -----------------------------------------------------------------------------------------------------------------------
> -Anand Moon
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Odroid U3 mutex deadlock.
2015-12-13 23:45 ` Krzysztof Kozlowski
@ 2016-01-02 5:14 ` Anand Moon
2016-01-04 10:38 ` Marek Szyprowski
0 siblings, 1 reply; 5+ messages in thread
From: Anand Moon @ 2016-01-02 5:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, Linux Kernel, Javier Martinez Canillas,
Kukjin Kim, linux-arm-kernel, Marek Szyprowski
Hi Krzysztof
On 14 December 2015 at 05:15, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> On 12.12.2015 13:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>
> This is not a deadlock yet, just a report from lockdep. Could be a real
> issue, could be false positive, maybe some locks miss nesting annotations.
>
> Typical information for bug report would be useful, like the exact
> version (it is mentioned in lockdep report but is it really correct?)
> and reproducibility. And of course git-bisect would be nice to have, see:
> Documentation/BUG-HUNTING
>
> Best regards,
> Krzysztof
>
>
Thanks for your inputs. I narrowed down to this commit.
----------------------------------------------------------------------------------
commit ec459c0c77faca53cf161830cb264e51bb1abba6
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Wed Feb 4 23:44:15 2015 +0900
ARM: dts: add dependency between TV and LCD0 power domains for exynos4
TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
This dependency is modelled by making TV power domains a sub-domain of
LCD0 power domain.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
-------------------------------------------------------------------------------------
After reverting this I am not observing below lockdep warning report.
But after reverting this patch I observer another bug.
Best regards.
-Anand Moon
>> ------------------------------------------------------------------------------------------------------------------
>>
>> [ 2.937531] =============================================
>> [ 2.938733] [ INFO: possible recursive locking detected ]
>> [ 2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [ 2.948195] ---------------------------------------------
>> [ 2.953577] swapper/0/1 is trying to acquire lock:
>> [ 2.958351] (&genpd->lock){+.+...}, at: [<c0361550>]
>> __genpd_poweron+0x64/0x108
>> [ 2.965727]
>> [ 2.965727] but task is already holding lock:
>> [ 2.971543] (&genpd->lock){+.+...}, at: [<c0361af8>]
>> genpd_dev_pm_attach+0x168/0x1b8
>> [ 2.979355]
>> [ 2.979355] other info that might help us debug this:
>> [ 2.985865] Possible unsafe locking scenario:
>> [ 2.985865]
>> [ 2.991768] CPU0
>> [ 2.994198] ----
>> [ 2.996628] lock(&genpd->lock);
>> [ 2.999926] lock(&genpd->lock);
>> [ 3.003225]
>> [ 3.003225] *** DEADLOCK ***
>> [ 3.003225]
>> [ 3.009128] May be due to missing lock nesting notation
>> [ 3.009128]
>> [ 3.015900] 3 locks held by swapper/0/1:
>> [ 3.019804] #0: (&dev->mutex){......}, at: [<c0350910>]
>> __driver_attach+0x48/0x98
>> [ 3.027442] #1: (&dev->mutex){......}, at: [<c0350920>]
>> __driver_attach+0x58/0x98
>> [ 3.035081] #2: (&genpd->lock){+.+...}, at: [<c0361af8>]
>> genpd_dev_pm_attach+0x168/0x1b8
>> [ 3.043326]
>> [ 3.043326] stack backtrace:
>> [ 3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
>> [ 3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 3.060444] [<c0016c98>] (unwind_backtrace) from [<c00139c4>]
>> (show_stack+0x10/0x14)
>> [ 3.068163] [<c00139c4>] (show_stack) from [<c0270df0>]
>> (dump_stack+0x84/0xc4)
>> [ 3.075367] [<c0270df0>] (dump_stack) from [<c00780b8>]
>> (__lock_acquire+0x1f88/0x215c)
>> [ 3.083262] [<c00780b8>] (__lock_acquire) from [<c007886c>]
>> (lock_acquire+0xa4/0xd0)
>> [ 3.090990] [<c007886c>] (lock_acquire) from [<c0641f2c>]
>> (mutex_lock_nested+0x70/0x4d4)
>> [ 3.099061] [<c0641f2c>] (mutex_lock_nested) from [<c0361550>]
>> (__genpd_poweron+0x64/0x108)
>> [ 3.107393] [<c0361550>] (__genpd_poweron) from [<c0361b00>]
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [ 3.115986] [<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>]
>> (platform_drv_probe+0x2c/0xac)
>> [ 3.124667] [<c03520a8>] (platform_drv_probe) from [<c03507d4>]
>> (driver_probe_device+0x208/0x2fc)
>> [ 3.133519] [<c03507d4>] (driver_probe_device) from [<c035095c>]
>> (__driver_attach+0x94/0x98)
>> [ 3.141939] [<c035095c>] (__driver_attach) from [<c034ec14>]
>> (bus_for_each_dev+0x68/0x9c)
>> [ 3.150097] [<c034ec14>] (bus_for_each_dev) from [<c034fec8>]
>> (bus_add_driver+0x1a0/0x218)
>> [ 3.158344] [<c034fec8>] (bus_add_driver) from [<c035115c>]
>> (driver_register+0x78/0xf8)
>> [ 3.166330] [<c035115c>] (driver_register) from [<c0338488>]
>> (exynos_drm_register_drivers+0x28/0x74)
>> [ 3.175441] [<c0338488>] (exynos_drm_register_drivers) from
>> [<c0338594>] (exynos_drm_init+0x6c/0xc4)
>> [ 3.184556] [<c0338594>] (exynos_drm_init) from [<c00097f4>]
>> (do_one_initcall+0x90/0x1dc)
>> [ 3.192718] [<c00097f4>] (do_one_initcall) from [<c0895e08>]
>> (kernel_init_freeable+0x158/0x1f8)
>> [ 3.201396] [<c0895e08>] (kernel_init_freeable) from [<c063ecac>]
>> (kernel_init+0x8/0xe8)
>> [ 3.209469] [<c063ecac>] (kernel_init) from [<c000f7d0>]
>> (ret_from_fork+0x14/0x24)
>> [ 3.217932] exynos-hdmi 12d00000.hdmi: GPIO lookup for consumer hpd
>> [ 3.223293] exynos-hdmi 12d00000.hdmi: using device tree for GPIO lookup
>> [ 3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
>> property of node '/hdmi@12D00000[0]'
>> [ 3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
>> node '/hdmi@12D00000[0]' - status (0)
>> [ 3.253430] exynos-drm exynos-drm: bound 12c10000.mixer (ops
>> mixer_component_ops)
>> [ 3.256216] exynos-drm exynos-drm: bound 12d00000.hdmi (ops
>> hdmi_component_ops)
>> [ 3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 3.269812] [drm] No driver support for vblank timestamp query.
>> [ 3.323251] exynos-drm exynos-drm: fb0: frame buffer device
>> [ 3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>
>> -----------------------------------------------------------------------------------------------------------------------
>> -Anand Moon
>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Odroid U3 mutex deadlock.
2016-01-02 5:14 ` Anand Moon
@ 2016-01-04 10:38 ` Marek Szyprowski
0 siblings, 0 replies; 5+ messages in thread
From: Marek Szyprowski @ 2016-01-04 10:38 UTC (permalink / raw)
To: Anand Moon, Krzysztof Kozlowski
Cc: linux-samsung-soc, Linux Kernel, Javier Martinez Canillas,
Kukjin Kim, linux-arm-kernel
Hi Anand,
On 2016-01-02 06:14, Anand Moon wrote:
> Hi Krzysztof
>
> On 14 December 2015 at 05:15, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> On 12.12.2015 13:32, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> I am just observing this deadlock om my Odroid U3.
>> This is not a deadlock yet, just a report from lockdep. Could be a real
>> issue, could be false positive, maybe some locks miss nesting annotations.
>>
>> Typical information for bug report would be useful, like the exact
>> version (it is mentioned in lockdep report but is it really correct?)
>> and reproducibility. And of course git-bisect would be nice to have, see:
>> Documentation/BUG-HUNTING
>>
>> Best regards,
>> Krzysztof
>>
>>
> Thanks for your inputs. I narrowed down to this commit.
> ----------------------------------------------------------------------------------
> commit ec459c0c77faca53cf161830cb264e51bb1abba6
> Author: Marek Szyprowski <m.szyprowski@samsung.com>
> Date: Wed Feb 4 23:44:15 2015 +0900
>
> ARM: dts: add dependency between TV and LCD0 power domains for exynos4
>
> TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
> This dependency is modelled by making TV power domains a sub-domain of
> LCD0 power domain.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Kukjin Kim <kgene@kernel.org>
> -------------------------------------------------------------------------------------
> After reverting this I am not observing below lockdep warning report.
> But after reverting this patch I observer another bug.
The mentioned lockdep warning is a false positive. Such warning is
reported for
every subdomain present in a system. As you noticed that removing dependency
between power domains also removes this warning, but it will introduce real
problems with power on/off sequences of graphics devices.
I will send a patch for genpd core fixing the deplock warning. Thanks for
reporting the issue and pointing a good place to start digging in the
source :)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-04 10:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-12 4:32 Odroid U3 mutex deadlock Anand Moon
[not found] ` <CAE-5t2stNAGnHSW1RG9Ek8Zas6c3wgdULYP9sFRw=9LyLz+rLA@mail.gmail.com>
2015-12-13 2:36 ` Anand Moon
2015-12-13 23:45 ` Krzysztof Kozlowski
2016-01-02 5:14 ` Anand Moon
2016-01-04 10:38 ` Marek Szyprowski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).