On Mon, Mar 4, 2013 at 11:28 PM, Aaron Lu <aaron.lu@xxxxxxxxx> wrote:
> On 03/05/2013 03:55 AM, Maciej Rutecki wrote:
>> Last known good: 3.8.0
>> Bad version: 3.9-rc1
>>
>> [ 6.116492] =====================================
>> [ 6.116614] [ BUG: ktpacpi_nvramd/446 still has locks held! ]
>> [ 6.116737] 3.9.0-rc1 #1 Not tainted
>> [ 6.116821] -------------------------------------
>> [ 6.116900] 1 lock held by ktpacpi_nvramd/446:
>> [ 6.116973] #0: (&hotkey_thread_mutex){+.+...}, at: [<ffffffffa024e87e>]
>> hotkey_kthread+0x1f/0x354 [thinkpad_acpi]
>> [ 6.117193]
>> [ 6.117193] stack backtrace:
>> [ 6.117268] Pid: 446, comm: ktpacpi_nvramd Not tainted 3.9.0-rc1 #1
>> [ 6.117381] Call Trace:
>> [ 6.117445] [<ffffffff810877ea>] debug_check_no_locks_held+0x8f/0x93
>> [ 6.117600] [<ffffffff8107d8ac>] set_freezable+0x3e/0x64
>> [ 6.117703] input: ThinkPad Extra Buttons as
>> /devices/platform/thinkpad_acpi/input/input5
>> [ 6.117918] [<ffffffffa024e890>] hotkey_kthread+0x31/0x354 [thinkpad_acpi]
>> [ 6.118088] [<ffffffffa024e85f>] ? issue_volchange.29885+0x54/0x54
>> [thinkpad_acpi]
>> [ 6.118250] [<ffffffff8105e296>] kthread+0xac/0xb4
>> [ 6.118356] [<ffffffff8105e1ea>] ? __kthread_parkme+0x60/0x60
>> [ 6.118491] [<ffffffff814b243c>] ret_from_fork+0x7c/0xb0
>> [ 6.118614] [<ffffffff8105e1ea>] ? __kthread_parkme+0x60/0x60
>>
>> Config:
>> http://mrutecki.pl/download/kernel/3.9.0-rc1/config-3.9.0-rc1
>>
>> full dmesg:
>> http://mrutecki.pl/download/kernel/3.9.0-rc1/dmesg-3.9.0-rc1.txt
>>
>
> Thanks for the report!
>
> Looks like the following commit is related:
> commit 6aa9707099c4b25700940eb3d016f16c4434360d
> Author: Mandeep Singh Baines <msb@xxxxxxxxxxxx> Thu Feb 28 09:03:18 2013
>
> lockdep: check that no locks held at freeze time
>
> And the code to trigger this problem is here:
> static int hotkey_kthread(void *data)
> {
> struct tp_nvram_state s[2];
> u32 poll_mask, event_mask;
> unsigned int si, so;
> unsigned long t;
> unsigned int change_detector;
> unsigned int poll_freq;
> bool was_frozen;
>
> mutex_lock(&hotkey_thread_mutex);
>
> if (tpacpi_lifecycle == TPACPI_LIFE_EXITING)
> goto exit;
>
> set_freezable();
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> in thinkpad_acpi.c.
>
> I don't know much about freeze, I've no idea what is the problem.
> So Mandeep and Henrique, can you please kindly take a look? Thanks.
>
Hi Aaron,
I will take a look at this.
In general, you don't want to grab a lock and freeze. You will block
suspend because another thread may try go grab the lock. In the case
of cgroup freezer, you could cause a deadlock.
There is also discussion happening on this thread:
https://lkml.org/lkml/2013/3/4/221
Regards,
Mandeep
> -Aaron
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
