From: Hauke Mehrtens <hauke@hauke-m.de>
To: Arend van Spriel <arend@broadcom.com>
Cc: "Joe Perches" <joe@perches.com>,
brcm80211-dev-list@broadcom.com,
linux-wireless <linux-wireless@vger.kernel.org>,
"Rafał Miłecki" <zajec5@gmail.com>
Subject: Re: fyi: scheduling while atomic dmesg output 3.12-rc1
Date: Wed, 18 Sep 2013 15:57:01 +0200 [thread overview]
Message-ID: <5239B12D.3040206@hauke-m.de> (raw)
In-Reply-To: <52397023.2080000@broadcom.com>
On 09/18/2013 11:19 AM, Arend van Spriel wrote:
> On 09/17/2013 07:45 PM, Joe Perches wrote:
>> <3>[ 11.206312] BUG: scheduling while atomic:
>> NetworkManager/866/0x00000200
>
> Thanks, Joe
>
> I got a report on this few days ago. It was introduced by bcma API
> change and I already sent email to the committer of that change, ie.
> Hauke Mehrtens. Hope it will be settled soon how to fix this.
>
> Gr. AvS
Hi,
I see four solutions for the problem:
1. convert the usleep_range(1000, 2000) into udelay(1000) in
drivers/bcma/driver_pci.c
2. remove the call of bcma_core_pci_power_save() from bcma_core_pci_up()
so that it does not get called by brcmsmac.
3. remove the call of bcma_core_pci_power_save() from bcma_core_pci_up()
and move the call to somewhere out of the big spin lock.
4. convert the big brmcsmac spin lock into a mutex lock and use an
additional spin lock for the parts where it is actually needed.
For 3.12 I am for solution 1 or 2 and for the long term 3.13? I am for
solution 4, but that needs bigger changes.
Hauke
next prev parent reply other threads:[~2013-09-18 13:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1379439942.2012.16.camel@joe-AO722>
2013-09-18 9:19 ` fyi: scheduling while atomic dmesg output 3.12-rc1 Arend van Spriel
2013-09-18 13:57 ` Hauke Mehrtens [this message]
2013-09-18 17:11 ` Arend van Spriel
2013-09-27 6:25 ` Rafał Miłecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5239B12D.3040206@hauke-m.de \
--to=hauke@hauke-m.de \
--cc=arend@broadcom.com \
--cc=brcm80211-dev-list@broadcom.com \
--cc=joe@perches.com \
--cc=linux-wireless@vger.kernel.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.