Re: fyi: scheduling while atomic dmesg output 3.12-rc1

Re: fyi: scheduling while atomic dmesg output 3.12-rc1

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 5260 bytes --]

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

> <4>[   11.206325] Modules linked in: snd_hda_codec_realtek arc4 brcmsmac cordic brcmutil b43 mac80211 joydev cfg80211 ssb acer_wmi sparse_keymap snd_hda_intel snd_hda_codec snd_hwdep snd_pcm i2c_piix4 psmouse serio_raw k10temp snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer radeon bcma video snd wmi mac_hid parport_pc ppdev ttm rfcomm bnep bluetooth soundcore drm_kms_helper drm i2c_algo_bit binfmt_misc lp parport r8169 mii
> <4>[   11.206419] CPU: 0 PID: 866 Comm: NetworkManager Not tainted 3.12.0-rc1+ #41
> <4>[   11.206424] Hardware name: Acer AO725/ZA10_BZ, BIOS V2.12 04/16/2013
> <4>[   11.206430]  00000000 00000000 f159b828 c15e711b 00000000 f159b840 c15e3ffb c17ab9d0
> <4>[   11.206446]  f6c84320 00000362 00000200 f159b8cc c15eb79c c12de6a0 00000000 f159b8f0
> <4>[   11.206461]  f7bb69b0 f159b86c c106259e 00000000 c19b9940 c19b9940 f159b8bc c106323d
> <4>[   11.206476] Call Trace:
> <4>[   11.206494]  [<c15e711b>] dump_stack+0x41/0x52
> <4>[   11.206503]  [<c15e3ffb>] __schedule_bug+0x4e/0x5c
> <4>[   11.206512]  [<c15eb79c>] __schedule+0x78c/0x7a0
> <4>[   11.206523]  [<c12de6a0>] ? timerqueue_add+0x50/0xb0
> <4>[   11.206534]  [<c106259e>] ? enqueue_hrtimer+0x1e/0x70
> <4>[   11.206544]  [<c106323d>] ? __hrtimer_start_range_ns+0x16d/0x460
> <4>[   11.206552]  [<c15ebf73>] schedule+0x23/0x60
> <4>[   11.206560]  [<c15eab9c>] schedule_hrtimeout_range_clock+0xbc/0x160
> <4>[   11.206569]  [<c10626c0>] ? update_rmtp+0x90/0x90
> <4>[   11.206578]  [<c1063586>] ? hrtimer_start_range_ns+0x26/0x30
> <4>[   11.206586]  [<c15eac57>] schedule_hrtimeout_range+0x17/0x20
> <4>[   11.206594]  [<c104d13d>] usleep_range+0x3d/0x40
> <4>[   11.206612]  [<f88a0e27>] bcma_pcie_mdio_set_phy.isra.3+0x47/0x70 [bcma]
> <4>[   11.206626]  [<f88a0efa>] bcma_pcie_mdio_write.isra.4+0xaa/0xc0 [bcma]
> <4>[   11.206640]  [<f88a10d8>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
> <4>[   11.206653]  [<f88a1128>] bcma_core_pci_power_save+0x38/0x70 [bcma]
> <4>[   11.206666]  [<f88a126f>] bcma_core_pci_up+0x1f/0x50 [bcma]
> <4>[   11.206693]  [<f8eb523e>] brcms_c_up+0xee/0x3b0 [brcmsmac]
> <4>[   11.206712]  [<f8eab890>] brcms_up+0x20/0x30 [brcmsmac]
> <4>[   11.206731]  [<f8eac1a7>] brcms_ops_start+0x247/0x2e0 [brcmsmac]
> <4>[   11.206740]  [<c15e420a>] ? printk+0x4d/0x4f
> <4>[   11.206750]  [<c15278b0>] ? fib_rules_event+0x20/0x190
> <4>[   11.206798]  [<f941464c>] ieee80211_do_open+0x2fc/0xca0 [mac80211]
> <4>[   11.206807]  [<c1064dae>] ? __raw_notifier_call_chain+0x1e/0x30
> <4>[   11.206815]  [<c1064ddf>] ? raw_notifier_call_chain+0x1f/0x30
> <4>[   11.206856]  [<f941504d>] ieee80211_open+0x5d/0x60 [mac80211]
> <4>[   11.206867]  [<c151225b>] __dev_open+0xab/0x140
> <4>[   11.206875]  [<c15ed044>] ? _raw_spin_unlock_bh+0x14/0x20
> <4>[   11.206884]  [<c1512521>] __dev_change_flags+0x81/0x160
> <4>[   11.206893]  [<c15126b1>] dev_change_flags+0x21/0x60
> <4>[   11.206902]  [<c151d58d>] do_setlink+0x2bd/0x810
> <4>[   11.206913]  [<c12f6b22>] ? nla_parse+0x22/0xa0
> <4>[   11.206921]  [<c151f85e>] rtnl_newlink+0x36e/0x560
> <4>[   11.206932]  [<c1532b00>] ? __netlink_sendskb+0x10/0x120
> <4>[   11.206942]  [<c1268f74>] ? security_sock_rcv_skb+0x14/0x20
> <4>[   11.206951]  [<c1521200>] ? sk_run_filter+0x4a0/0x540
> <4>[   11.206960]  [<c129ee83>] ? apparmor_capable+0x23/0x70
> <4>[   11.206968]  [<c126956c>] ? security_capable+0x1c/0x30
> <4>[   11.206977]  [<c151f356>] rtnetlink_rcv_msg+0x86/0x220
> <4>[   11.206988]  [<c114a41a>] ? __kmalloc_track_caller+0x4a/0x150
> <4>[   11.206997]  [<c1507453>] ? __skb_recv_datagram+0xc3/0x3d0
> <4>[   11.207006]  [<c1504a60>] ? __alloc_skb+0x60/0x250
> <4>[   11.207014]  [<c151f2d0>] ? __rtnl_unlock+0x20/0x20
> <4>[   11.207022]  [<c1535506>] netlink_rcv_skb+0x86/0xa0
> <4>[   11.207030]  [<c151be9c>] rtnetlink_rcv+0x1c/0x30
> <4>[   11.207038]  [<c1534e74>] netlink_unicast+0x134/0x1a0
> <4>[   11.207046]  [<c1535122>] netlink_sendmsg+0x242/0x3e0
> <4>[   11.207055]  [<c14fb9f5>] sock_sendmsg+0x85/0xc0
> <4>[   11.207064]  [<c12e3535>] ? _copy_from_user+0x35/0x50
> <4>[   11.207072]  [<c15069af>] ? verify_iovec+0x3f/0xb0
> <4>[   11.207080]  [<c14fbcc9>] ___sys_sendmsg+0x299/0x2b0
> <4>[   11.207087]  [<c14fbd30>] ? kernel_sendmsg+0x50/0x50
> <4>[   11.207097]  [<c14f9f45>] ? sockfd_lookup_light+0x25/0x70
> <4>[   11.207107]  [<c107500d>] ? update_curr+0x12d/0x1e0
> <4>[   11.207116]  [<c10724a0>] ? __enqueue_entity+0x70/0x80
> <4>[   11.207124]  [<c1072405>] ? __dequeue_entity+0x25/0x40
> <4>[   11.207133]  [<c1073b16>] ? set_next_entity+0xa6/0xc0
> <4>[   11.207141]  [<c14fca2e>] __sys_sendmsg+0x3e/0x70
> <4>[   11.207149]  [<c14fca76>] SyS_sendmsg+0x16/0x20
> <4>[   11.207157]  [<c14fd193>] SyS_socketcall+0x2d3/0x300
> <4>[   11.207166]  [<c15f4c5b>] ? do_IRQ+0x4b/0xc0
> <4>[   11.207238]  [<c15f4681>] sysenter_do_call+0x12/0x22
>
>
>


[-- Attachment #2: Fwd: brcmsmac follow up.eml --]
[-- Type: application/x-extension-eml, Size: 112303 bytes --]

Re: fyi: scheduling while atomic dmesg output 3.12-rc1

[Hauke Mehrtens]

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

Re: fyi: scheduling while atomic dmesg output 3.12-rc1

[Arend van Spriel]

On 09/18/2013 03:57 PM, Hauke Mehrtens wrote:
> 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.

Agree. When looking into this I considered option 4 would be a bigger 
work, but I agree we should aim for that in the long term. For the short 
term I would say option 2 makes sense although I guess the power_save 
call is there for a reason. So I will also look if option 3 is doable.

Regards,
Arend

Re: fyi: scheduling while atomic dmesg output 3.12-rc1

[Rafał Miłecki]

2013/9/18 Arend van Spriel <arend@broadcom.com>:
> On 09/18/2013 03:57 PM, Hauke Mehrtens wrote:
>>
>> 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.
>
>
> Agree. When looking into this I considered option 4 would be a bigger work,
> but I agree we should aim for that in the long term. For the short term I
> would say option 2 makes sense although I guess the power_save call is there
> for a reason. So I will also look if option 3 is doable.

I'm OK with that (sorry, was on holidays for the last week).

-- 
Rafał