* Lock problem with latest b43 patches
@ 2007-08-19 4:45 Larry Finger
2007-08-19 12:16 ` Michael Buesch
2007-08-20 11:26 ` Johannes Berg
0 siblings, 2 replies; 6+ messages in thread
From: Larry Finger @ 2007-08-19 4:45 UTC (permalink / raw)
To: Michael Buesch; +Cc: Broadcom Linux, wireless
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: [<ffffffff80224401>] do_page_fault+0x38e/0x835
but task is already holding lock:
(&inode->i_mutex){--..}, at: [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&inode->i_mutex){--..}:
[<ffffffff80252d52>] __lock_acquire+0xad4/0xcf0
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff80252ff3>] lock_acquire+0x85/0xa9
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff803fe34a>] __mutex_lock_slowpath+0xef/0x290
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff88600d7d>] nfs_revalidate_mapping+0x6d/0xac [nfs]
[<ffffffff885fe7e1>] nfs_file_mmap+0x4d/0x65 [nfs]
[<ffffffff80284371>] mmap_region+0x222/0x431
[<ffffffff803ff491>] __down_write_nested+0x1a/0xab
[<ffffffff80284a67>] do_mmap_pgoff+0x2ce/0x333
[<ffffffff802122eb>] sys_mmap+0x90/0x119
[<ffffffff8020c07e>] system_call+0x7e/0x83
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&mm->mmap_sem){----}:
[<ffffffff80252c50>] __lock_acquire+0x9d2/0xcf0
[<ffffffff802fecdc>] __down_read_trylock+0x16/0x46
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff80252ff3>] lock_acquire+0x85/0xa9
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff8024d161>] down_read+0x3e/0x4a
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff80252f20>] __lock_acquire+0xca2/0xcf0
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff80251be9>] mark_held_locks+0x4a/0x6a
[<ffffffff803fe4d2>] __mutex_lock_slowpath+0x277/0x290
[<ffffffff804001fd>] error_exit+0x0/0x96
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff8029f7fc>] pipe_read+0x106/0x374
[<ffffffff8029f7c3>] pipe_read+0xcd/0x374
[<ffffffff80298c81>] do_sync_read+0xe2/0x126
[<ffffffff8024a4e4>] autoremove_wake_function+0x0/0x38
[<ffffffff802ce09e>] dnotify_parent+0x6b/0x73
[<ffffffff802994c4>] vfs_read+0xcc/0x155
[<ffffffff80299889>] sys_read+0x47/0x6f
[<ffffffff8020c07e>] system_call+0x7e/0x83
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
1 lock held by NetworkManager/4114:
#0: (&inode->i_mutex){--..}, at: [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
stack backtrace:
Call Trace:
[<ffffffff80251023>] print_circular_bug_tail+0x70/0x7b
[<ffffffff80252c50>] __lock_acquire+0x9d2/0xcf0
[<ffffffff802fecdc>] __down_read_trylock+0x16/0x46
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff80252ff3>] lock_acquire+0x85/0xa9
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff8024d161>] down_read+0x3e/0x4a
[<ffffffff80224401>] do_page_fault+0x38e/0x835
[<ffffffff80252f20>] __lock_acquire+0xca2/0xcf0
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff80251be9>] mark_held_locks+0x4a/0x6a
[<ffffffff803fe4d2>] __mutex_lock_slowpath+0x277/0x290
[<ffffffff804001fd>] error_exit+0x0/0x96
[<ffffffff803fe515>] mutex_lock+0x2a/0x2e
[<ffffffff8029f7fc>] pipe_read+0x106/0x374
[<ffffffff8029f7c3>] pipe_read+0xcd/0x374
[<ffffffff80298c81>] do_sync_read+0xe2/0x126
[<ffffffff8024a4e4>] autoremove_wake_function+0x0/0x38
[<ffffffff802ce09e>] dnotify_parent+0x6b/0x73
[<ffffffff802994c4>] vfs_read+0xcc/0x155
[<ffffffff80299889>] sys_read+0x47/0x6f
[<ffffffff8020c07e>] system_call+0x7e/0x83
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lock problem with latest b43 patches
2007-08-19 4:45 Lock problem with latest b43 patches Larry Finger
@ 2007-08-19 12:16 ` Michael Buesch
2007-08-19 16:07 ` Larry Finger
2007-08-20 11:26 ` Johannes Berg
1 sibling, 1 reply; 6+ messages in thread
From: Michael Buesch @ 2007-08-19 12:16 UTC (permalink / raw)
To: Larry Finger; +Cc: Broadcom Linux, wireless
On Sunday 19 August 2007 06:45:00 Larry Finger wrote:
> 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:
Are you sure this is caused by my patches? I don't see how that's possible.
How to reproduce?
--
Greetings Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lock problem with latest b43 patches
2007-08-19 12:16 ` Michael Buesch
@ 2007-08-19 16:07 ` Larry Finger
0 siblings, 0 replies; 6+ messages in thread
From: Larry Finger @ 2007-08-19 16:07 UTC (permalink / raw)
To: Michael Buesch; +Cc: Broadcom Linux, wireless
Michael Buesch wrote:
> On Sunday 19 August 2007 06:45:00 Larry Finger wrote:
>> 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:
>
> Are you sure this is caused by my patches? I don't see how that's possible.
> How to reproduce?
It's probably not your patches, but some unusual locking interaction involving NetworkManager,
wpa_supplicant, and mac80211. The involvement of b43 may be incidental. It must have accidentally
triggered just after I installed your patches. I cannot reproduce it today. No doubt it will show up
again.
Larry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lock problem with latest b43 patches
2007-08-19 4:45 Lock problem with latest b43 patches Larry Finger
2007-08-19 12:16 ` Michael Buesch
@ 2007-08-20 11:26 ` Johannes Berg
2007-08-20 17:48 ` Larry Finger
1 sibling, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2007-08-20 11:26 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, wireless, Broadcom Linux
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Sat, 2007-08-18 at 23:45 -0500, Larry Finger wrote:
> -> #1 (&inode->i_mutex){--..}:
> [<ffffffff80252d52>] __lock_acquire+0xad4/0xcf0
> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
> [<ffffffff80252ff3>] lock_acquire+0x85/0xa9
> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
> [<ffffffff803fe34a>] __mutex_lock_slowpath+0xef/0x290
> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
> [<ffffffff88600d7d>] nfs_revalidate_mapping+0x6d/0xac [nfs]
> [<ffffffff885fe7e1>] nfs_file_mmap+0x4d/0x65 [nfs]
Are you running on NFS? This is a bit weird but not related to wireless
at all, seems to be dnotify/NFS interaction.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lock problem with latest b43 patches
2007-08-20 11:26 ` Johannes Berg
@ 2007-08-20 17:48 ` Larry Finger
2007-08-21 18:58 ` Johannes Berg
0 siblings, 1 reply; 6+ messages in thread
From: Larry Finger @ 2007-08-20 17:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: Michael Buesch, wireless, Broadcom Linux
Johannes Berg wrote:
> On Sat, 2007-08-18 at 23:45 -0500, Larry Finger wrote:
>
>> -> #1 (&inode->i_mutex){--..}:
>> [<ffffffff80252d52>] __lock_acquire+0xad4/0xcf0
>> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
>> [<ffffffff80252ff3>] lock_acquire+0x85/0xa9
>> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
>> [<ffffffff803fe34a>] __mutex_lock_slowpath+0xef/0x290
>> [<ffffffff803fe515>] mutex_lock+0x2a/0x2e
>> [<ffffffff88600d7d>] nfs_revalidate_mapping+0x6d/0xac [nfs]
>> [<ffffffff885fe7e1>] nfs_file_mmap+0x4d/0x65 [nfs]
>
> Are you running on NFS? This is a bit weird but not related to wireless
> at all, seems to be dnotify/NFS interaction.
My / and /home partitions are local, but I do have mounted NFS partitions. Whatever happened here
has been a one-time only event, at least so far. Until it happens again, I'll assume that an
electron got crosswise somewhere. :)
Larry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lock problem with latest b43 patches
2007-08-20 17:48 ` Larry Finger
@ 2007-08-21 18:58 ` Johannes Berg
0 siblings, 0 replies; 6+ messages in thread
From: Johannes Berg @ 2007-08-21 18:58 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, wireless, Broadcom Linux
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
On Mon, 2007-08-20 at 12:48 -0500, Larry Finger wrote:
> My / and /home partitions are local, but I do have mounted NFS partitions. Whatever happened here
> has been a one-time only event, at least so far. Until it happens again, I'll assume that an
> electron got crosswise somewhere. :)
I suppose it's unlikely because it looks like there was a page fault of
a memory mapped file involved. It may be worth sending it to the NFS
maintainer anyway.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-08-22 9:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-19 4:45 Lock problem with latest b43 patches Larry Finger
2007-08-19 12:16 ` Michael Buesch
2007-08-19 16:07 ` Larry Finger
2007-08-20 11:26 ` Johannes Berg
2007-08-20 17:48 ` Larry Finger
2007-08-21 18:58 ` Johannes Berg
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).