lkml.org 
[lkml]   [2013]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [REGRESSION] [3.9-rc1] BUG: ktpacpi_nvramd/446 still has locks held!
From
On Mon, Mar 4, 2013 at 11:28 PM, Aaron Lu <aaron.lu@intel.com> 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@chromium.org> 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
>


\
 
 \ /
  Last update: 2013-03-05 17:21    [W:0.085 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site