From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]:53094 "EHLO mtiwmhc13.worldnet.att.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751175AbXHSEpD (ORCPT ); Sun, 19 Aug 2007 00:45:03 -0400 Message-ID: <46C7CACC.2000000@lwfinger.net> Date: Sat, 18 Aug 2007 23:45:00 -0500 From: Larry Finger MIME-Version: 1.0 To: Michael Buesch CC: Broadcom Linux , wireless Subject: Lock problem with latest b43 patches Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: Using the latest set of 6 patches posted about 5 hours ago, I get the following locking problem with a BCM4311 using WPA-PSK TKIP encryption controlled by NetworkManager: b43-phy1 ERROR: Adjusting Local Oscillator to an uncalibrated control pair: rfatt=3,no-padmix bbatt=0 eth1: Initial auth_alg=0 eth1: authenticate with AP 00:1a:70:46:ba:b1 eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:1a:70:46:ba:b1 eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=1) eth1: associated eth1: switched to short barker preamble (BSSID=00:1a:70:46:ba:b1) ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.23-rc3-Ldev-gf5a42059-dirty #16 ------------------------------------------------------- NetworkManager/4114 is trying to acquire lock: (&mm->mmap_sem){----}, at: [] do_page_fault+0x38e/0x835 but task is already holding lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x2a/0x2e which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&inode->i_mutex){--..}: [] __lock_acquire+0xad4/0xcf0 [] mutex_lock+0x2a/0x2e [] lock_acquire+0x85/0xa9 [] mutex_lock+0x2a/0x2e [] __mutex_lock_slowpath+0xef/0x290 [] mutex_lock+0x2a/0x2e [] nfs_revalidate_mapping+0x6d/0xac [nfs] [] nfs_file_mmap+0x4d/0x65 [nfs] [] mmap_region+0x222/0x431 [] __down_write_nested+0x1a/0xab [] do_mmap_pgoff+0x2ce/0x333 [] sys_mmap+0x90/0x119 [] system_call+0x7e/0x83 [] 0xffffffffffffffff -> #0 (&mm->mmap_sem){----}: [] __lock_acquire+0x9d2/0xcf0 [] __down_read_trylock+0x16/0x46 [] do_page_fault+0x38e/0x835 [] lock_acquire+0x85/0xa9 [] do_page_fault+0x38e/0x835 [] down_read+0x3e/0x4a [] do_page_fault+0x38e/0x835 [] __lock_acquire+0xca2/0xcf0 [] mutex_lock+0x2a/0x2e [] mark_held_locks+0x4a/0x6a [] __mutex_lock_slowpath+0x277/0x290 [] error_exit+0x0/0x96 [] mutex_lock+0x2a/0x2e [] pipe_read+0x106/0x374 [] pipe_read+0xcd/0x374 [] do_sync_read+0xe2/0x126 [] autoremove_wake_function+0x0/0x38 [] dnotify_parent+0x6b/0x73 [] vfs_read+0xcc/0x155 [] sys_read+0x47/0x6f [] system_call+0x7e/0x83 [] 0xffffffffffffffff other info that might help us debug this: 1 lock held by NetworkManager/4114: #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x2a/0x2e stack backtrace: Call Trace: [] print_circular_bug_tail+0x70/0x7b [] __lock_acquire+0x9d2/0xcf0 [] __down_read_trylock+0x16/0x46 [] do_page_fault+0x38e/0x835 [] lock_acquire+0x85/0xa9 [] do_page_fault+0x38e/0x835 [] down_read+0x3e/0x4a [] do_page_fault+0x38e/0x835 [] __lock_acquire+0xca2/0xcf0 [] mutex_lock+0x2a/0x2e [] mark_held_locks+0x4a/0x6a [] __mutex_lock_slowpath+0x277/0x290 [] error_exit+0x0/0x96 [] mutex_lock+0x2a/0x2e [] pipe_read+0x106/0x374 [] pipe_read+0xcd/0x374 [] do_sync_read+0xe2/0x126 [] autoremove_wake_function+0x0/0x38 [] dnotify_parent+0x6b/0x73 [] vfs_read+0xcc/0x155 [] sys_read+0x47/0x6f [] system_call+0x7e/0x83