1. 30 3月, 2011 5 次提交
  2. 29 3月, 2011 7 次提交
  3. 25 3月, 2011 7 次提交
  4. 24 3月, 2011 4 次提交
    • S
      ath9k: Fix TX queue stuck issue. · d78f4b3e
      Senthil Balasubramanian 提交于
      commit 86271e46 introduced a
      regression that caused mac80211 queues in stopped state.
      
      ath_drain_all_txq is called in driver flush which would reset
      the stopped flag and the mac80211 queues were never started
      after that. iperf traffic is completely stalled due to this issue.
      
      Restart the mac80211 queues in driver flush only if the txqs were
      drained.
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d78f4b3e
    • S
      ath9k: Fix kernel panic caused by invalid rate index access. · 19b96750
      Senthil Balasubramanian 提交于
      With the recent tx status optimization in mac80211, we bail out as
      and and when invalid rate index is found. So the behavior of resetting
      rate idx to -1 and count to 0 has changed for the rate indexes that
      were not part of the driver's retry series.
      
      This has resulted in ath9k using incorrect rate table index which
      caused the system to panic. Ideally ath9k need to loop only for the
      indexes that were part of the retry series and so simply use hw->max_rates
      as the loop counter.
      
      Pasted the stack trace of the panic issue for reference.
      
      [  754.093192] BUG: unable to handle kernel paging request at ffff88046a9025b0
      [  754.093256] IP: [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
      [  754.094888] Call Trace:
      [  754.094903]  <IRQ>
      [  754.094928]  [<ffffffffa051f883>] ieee80211_tx_status+0x203/0x9e0 [mac80211]
      [  754.094975]  [<ffffffffa053e305>] ? __ieee80211_wake_queue+0x125/0x140 [mac80211]
      [  754.095017]  [<ffffffffa02e66c9>] ath_tx_complete_buf+0x1b9/0x370 [ath9k]
      [  754.095054]  [<ffffffffa02e6fcf>] ath_tx_complete_aggr+0x51f/0xb50 [ath9k]
      [  754.095098]  [<ffffffffa05382a3>] ? ieee80211_prepare_and_rx_handle+0x173/0xab0 [mac80211]
      [  754.095148]  [<ffffffff81350e62>] ? _raw_spin_unlock_irqrestore+0x32/0x40
      [  754.095186]  [<ffffffffa02e9735>] ath_tx_tasklet+0x365/0x4b0 [ath9k]
      [  754.095224]  [<ffffffff8107a2a2>] ? clockevents_program_event+0x62/0xa0
      [  754.095261]  [<ffffffffa02e2628>] ath9k_tasklet+0x168/0x1c0 [ath9k]
      [  754.095298]  [<ffffffff8105599b>] tasklet_action+0x6b/0xe0
      [  754.095331]  [<ffffffff81056278>] __do_softirq+0x98/0x120
      [  754.095361]  [<ffffffff8100cd5c>] call_softirq+0x1c/0x30
      [  754.095393]  [<ffffffff8100efb5>] do_softirq+0x65/0xa0
      [  754.095423]  [<ffffffff810563fd>] irq_exit+0x8d/0x90
      [  754.095453]  [<ffffffff8100ebc1>] do_IRQ+0x61/0xe0
      [  754.095482]  [<ffffffff81351413>] ret_from_intr+0x0/0x15
      [  754.095513]  <EOI>
      [  754.095531]  [<ffffffff81014375>] ? native_sched_clock+0x15/0x70
      [  754.096475]  [<ffffffffa02bcfa6>] ? acpi_idle_enter_bm+0x24d/0x285 [processor]
      [  754.096475]  [<ffffffffa02bcf9f>] ? acpi_idle_enter_bm+0x246/0x285 [processor]
      [  754.096475]  [<ffffffff8127fab2>] cpuidle_idle_call+0x82/0x100
      [  754.096475]  [<ffffffff8100a236>] cpu_idle+0xa6/0xf0
      [  754.096475]  [<ffffffff81339bc1>] rest_init+0x91/0xa0
      [  754.096475]  [<ffffffff814efccd>] start_kernel+0x3fd/0x408
      [  754.096475]  [<ffffffff814ef347>] x86_64_start_reservations+0x132/0x136
      [  754.096475]  [<ffffffff814ef451>] x86_64_start_kernel+0x106/0x115
      [  754.096475] RIP  [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19b96750
    • A
      orinoco: Clear dangling pointer on hardware busy · a3ad38e8
      armadefuego@gmail.com 提交于
      On hardware busy the scan request pointer should be cleared, as higher
      levels will release. This avoids a crash when that pointer is
      erroneously used later.
      Signed-off-by: NJoseph J. Gunn <armadefuego@yahoo.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a3ad38e8
    • J
      iwlagn: fix error in command waiting · be36cacd
      Johannes Berg 提交于
      Clearly a mistake, since pointers won't suddenly
      change their value...
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      be36cacd
  5. 22 3月, 2011 11 次提交
  6. 21 3月, 2011 2 次提交
  7. 20 3月, 2011 4 次提交