• Emmanuel Grumbach's avatar
    iwlwifi: dvm: don't override mac80211's queue setting · f6b12952
    Emmanuel Grumbach authored
    Since we set IEEE80211_HW_QUEUE_CONTROL, we can let
    mac80211 do the queue assignement and don't need to
    override its decisions.
    While reassiging the same values is harmless of course,
    it triggered  a WARNING when iwlwifi and mac80211 came
    to different conclusions. This happened when mac80211 set
    IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the
    packet to the cab_queue because no stations were asleep.
    
    iwlwifi should not override mac80211's decicions for
    offchannel packets and packets to  be sent after DTIM,
    but it should override mac80211's decision for AMPDUs
    since we have a special queue for them. So for AMPDU,
    we still override info->hw_queue by the AMPDU queue.
    
    This avoids:
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
    Modules linked in:
    CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1
    Hardware name:                  /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
     0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000
     ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000
     ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e
    Call Trace:
     [<ffffffff8189aa62>] ? dump_stack+0x41/0x51
     [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
     [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
     [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
     [<ffffffff818a0040>] ? put_cred+0x15/0x15
     [<ffffffff815f6db4>] ? iwlagn_mac_tx+0x19/0x2f
     [<ffffffff8186cc45>] ? __ieee80211_tx+0x226/0x29b
     [<ffffffff8186e6bd>] ? ieee80211_tx+0xa6/0xb5
     [<ffffffff8186e98b>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
     [<ffffffff8171ce5f>] ? dev_hard_start_xmit+0x271/0x3ec
     [<ffffffff817351ac>] ? sch_direct_xmit+0x66/0x164
     [<ffffffff8171d1bf>] ? dev_queue_xmit+0x1e5/0x3c8
     [<ffffffff817fac5a>] ? packet_sendmsg+0xac5/0xb3d
     [<ffffffff81709a09>] ? sock_sendmsg+0x37/0x52
     [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
     [<ffffffff81713820>] ? verify_iovec+0x44/0x94
     [<ffffffff81709e63>] ? ___sys_sendmsg+0x1f1/0x283
     [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
     [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
     [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
     [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
     [<ffffffff81132f6f>] ? dput+0xe5/0xef
     [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
     [<ffffffff8170ae62>] ? __sys_sendmsg+0x39/0x57
     [<ffffffff818a7e39>] ? system_call_fastpath+0x16/0x1b
    ---[ end trace 1b3eb79359c1d1e6 ]---
    Reported-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
    Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    f6b12952
tx.c 40.2 KB