Nick Pelly wrote:
> On Sat, Feb 20, 2010 at 12:17 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
>> On Thu, Feb 18, 2010 at 1:04 PM, Nick Pelly <npelly@google.com> wrote:
>>> Since 2.6.32 we are seeing kernel panics like:
>>>
>>> [10651.110229] Unable to handle kernel paging request at virtual
>>> address 6b6b6b6b
>>> [10651.111968] Internal error: Oops: 5 [#1] PREEMPT
>>> [10651.113952] CPU: 0    Tainted: G        W   (2.6.32-59979-gd0c97db #1)
>>> [10651.114624] PC is at rfcomm_run+0xa04/0xdbc
>>> <...>
>>> [10651.406188] [<c031ad24>] (rfcomm_run+0xa04/0xdbc) from [<c006ce30>]
>>> (kthread+0x78/0x80)
>>> [10651.406585] [<c006ce30>] (kthread+0x78/0x80) from [<c002793c>]
>>> (kernel_thread_exit+0x0/0x8)
>>>
>>> (rfcomm_run() is all inlined so theres not much of a stack trace))

l2cap socket status might change while rfcomm is processing frames. And 
that makes rfcomm_process_rx to do double rfcomm_session_put() for 
incoming session reference. We cannot use sk_state.

Could you try with this patch if it helps to your problems also? My OPP 
problems went away with this patch.

I moved rfcomm_session_put() for incoming session to 
rfcomm_session_close in order to get more clear _hold()/_put() pairs.

-- 
Ville