[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyHCyUq=v4DED5yA+VdPhjG+1b270ZUq+mP_mS4ip_HcQ@mail.gmail.com>
Date: Sat, 14 Jan 2012 15:28:20 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Arend van Spriel <arend@...adcom.com>,
Rafał Miłecki <zajec5@...il.com>,
Larry Finger <Larry.Finger@...inger.net>,
Alwin Beukers <alwin@...adcom.com>,
Roland Vossen <rvossen@...adcom.com>,
"John W. Linville" <linville@...driver.com>,
Network Development <netdev@...r.kernel.org>,
"Franky (Zhenhui) Lin" <frankyl@...adcom.com>
Subject: Re: [0/5] bcma/brcmsmac suspend/resume cleanups and fixes
On Sat, Jan 14, 2012 at 3:08 PM, Dominique Martinet
<asmadeus@...ewreck.org> wrote:
>
> Right, I missed it. Suspend works as long as I don't use wireless
> before.
Ok. Your suspend hang may be related to the cfg80211_wext hang that is
apparently unrelated to the issues we saw.
> I still get a warning:
>
> [ 30.256946] ------------[ cut here ]------------
> [ 30.256956] WARNING: at drivers/base/core.c:194 device_release+0x6a/0x73()
Yes. This warning is annoying but harmless. We'll fix it some way
(possibly by just turning it back to a single line, like it used to
be), but for now you can just ignore it.
> brcmsmac seems to have a problem that looks like it's fixed in
> wireless-next, after a suspend if it's been used then all network
> operation hang (i.e. 'ip addr', something like resolving an host doesn't
> work but doesn't hang either, modprobe -r brcmsmac hangs as well)
> Here's the revelent information about this:
>
> [ 361.248353] INFO: task wpa_supplicant:9102 blocked for more than 120 seconds.
> [ 361.248362] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 361.248367] wpa_supplicant D ffff880062d68400 0 9102 1 0x00000000
> [ 361.248397] Call Trace:
> [ 361.248411] [<ffffffff81313307>] ? __mutex_lock_common.clone.5+0x114/0x179
> [ 361.248432] [<ffffffffa03bef8a>] ? cfg80211_wext_siwscan+0xbd/0x2dc [cfg80211]
> [ 361.248439] [<ffffffff81313137>] ? mutex_lock+0x12/0x25
> [ 361.248458] [<ffffffffa03f83c1>] ? ieee80211_request_scan+0x20/0x4e [mac80211]
Ok, judging by the call trace this seems to be a generic wireless bug,
likely not a brcmsmac bug. Presumably people like me (and obviously
wireless developers) avoid this by not using wpa_supplicant o
rsomething. You might want to enable LOCKDEP to verify - if it's a
deadlock (either direct, or ABBA) - lockdep should give you a big
splat immediately rather than having to wait for 2 minutes.
Linwille/David - can you please make sure the fix gets to my tree,
since it's apparently already ok in the development tree?
Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists