1. 10 4月, 2010 1 次提交
  2. 09 4月, 2010 3 次提交
  3. 08 4月, 2010 11 次提交
  4. 07 4月, 2010 4 次提交
  5. 04 4月, 2010 1 次提交
  6. 03 4月, 2010 3 次提交
    • Z
      iwlwifi: avoid Tx queue memory allocation in interface down · de0f60ea
      Zhu Yi 提交于
      We used to free all the Tx queues memory when interface is brought
      down and reallocate them again in interface up. This requires
      order-4 allocation for txq->cmd[]. In situations like s2ram, this
      usually leads to allocation failure in the memory subsystem. The
      patch fixed this problem by allocating the Tx queues memory only at
      the first time. Later iwl_down/iwl_up only initialize but don't
      free and reallocate them. The memory is freed at the device removal
      time. BTW, we have already done this for the Rx queue.
      
      This fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=15551Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      de0f60ea
    • S
      iwlwifi: use consistent table for tx data collect · 04f2dec1
      Shanyu Zhao 提交于
      When collecting tx data for non-aggregation packets in rate scaling, if
      the tx data matches "other table", it still uses current table to update
      the stats and calculate average throughput in function rs_collect_tx_data().
      This can mess up the rate scaling data structure and cause a kernel panic
      in a BUG_ON statement in rs_rate_scale_perform().
      
      To fix this bug, we pass table pointer instead of window pointer (pointed
      to by table pointer) to function rs_collect_tx_data() so that the table
      being used is consistent.
      Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
      Signed-off-by: NHenry Zhang <hongx.c.zhang@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      04f2dec1
    • Z
      iwlwifi: fix DMA allocation warnings · dd487449
      Zhu Yi 提交于
      Below warning is triggered sometimes at module removal time when
      CONFIG_DMA_API_DEBUG is enabled. This should be caused by we didn't
      unmap pending commands (enqueued, but no complete notification
      received) for the Tx command queue.
      
      [ 1583.107469] ------------[ cut here ]------------
      [ 1583.107539] WARNING: at lib/dma-debug.c:688
      dma_debug_device_change+0x13c/0x180()
      [ 1583.107617] Hardware name: ...
      [ 1583.107664] pci 0000:04:00.0: DMA-API: device driver has pending DMA
      allocations while released from device [count=1]
      [ 1583.107713] Modules linked in: ...
      [ 1583.111661] Pid: 16970, comm: modprobe Tainted: G        W
      2.6.34-rc1-wl #33
      [ 1583.111727] Call Trace:
      [ 1583.111779]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
      [ 1583.111833]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
      [ 1583.111908]  [<c0138e11>] warn_slowpath_common+0x71/0xd0
      [ 1583.111963]  [<c02a281c>] ? dma_debug_device_change+0x13c/0x180
      [ 1583.112016]  [<c0138ebb>] warn_slowpath_fmt+0x2b/0x30
      [ 1583.112086]  [<c02a281c>] dma_debug_device_change+0x13c/0x180
      [ 1583.112142]  [<c03e6c33>] notifier_call_chain+0x53/0x90
      [ 1583.112198]  [<c03e1ebe>] ? down_read+0x6e/0x90
      [ 1583.112271]  [<c015b229>] __blocking_notifier_call_chain+0x49/0x70
      [ 1583.112326]  [<c015b26f>] blocking_notifier_call_chain+0x1f/0x30
      [ 1583.112380]  [<c031931c>] __device_release_driver+0x8c/0xa0
      [ 1583.112451]  [<c03193bf>] driver_detach+0x8f/0xa0
      [ 1583.112538]  [<c0318382>] bus_remove_driver+0x82/0x100
      [ 1583.112595]  [<c0319ad9>] driver_unregister+0x49/0x80
      [ 1583.112671]  [<c024feb2>] ? sysfs_remove_file+0x12/0x20
      [ 1583.112727]  [<c02aa292>] pci_unregister_driver+0x32/0x80
      [ 1583.112791]  [<fc13a3c1>] iwl_exit+0x12/0x19 [iwlagn]
      [ 1583.112848]  [<c017940a>] sys_delete_module+0x15a/0x210
      [ 1583.112870]  [<c015a5db>] ? up_read+0x1b/0x30
      [ 1583.112893]  [<c029600c>] ? trace_hardirqs_off_thunk+0xc/0x10
      [ 1583.112924]  [<c0295ffc>] ? trace_hardirqs_on_thunk+0xc/0x10
      [ 1583.112947]  [<c03e6a1f>] ? do_page_fault+0x1ff/0x3c0
      [ 1583.112978]  [<c03e36f6>] ? restore_all_notrace+0x0/0x18
      [ 1583.113002]  [<c016aa70>] ? trace_hardirqs_on_caller+0x20/0x190
      [ 1583.113025]  [<c0102d58>] sysenter_do_call+0x12/0x38
      [ 1583.113054] ---[ end trace fc23e059cc4c2ced ]---
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      dd487449
  7. 02 4月, 2010 15 次提交
  8. 01 4月, 2010 1 次提交
  9. 31 3月, 2010 1 次提交