1. 09 4月, 2010 2 次提交
    • D
      tcp: Set CHECKSUM_UNNECESSARY in tcp_init_nondata_skb · 2626419a
      David S. Miller 提交于
      Back in commit 04a0551c
      ("loopback: Drop obsolete ip_summed setting") we stopped
      setting CHECKSUM_UNNECESSARY in the loopback xmit.
      
      This is because such a setting was a lie since it implies that the
      checksum field of the packet is properly filled in.
      
      Instead what happens normally is that CHECKSUM_PARTIAL is set and
      skb->csum is calculated as needed.
      
      But this was only happening for TCP data packets (via the
      skb->ip_summed assignment done in tcp_sendmsg()).  It doesn't
      happen for non-data packets like ACKs etc.
      
      Fix this by setting skb->ip_summed in the common non-data packet
      constructor.  It already is setting skb->csum to zero.
      
      But this reminds us that we still have things like ip_output.c's
      ip_dev_loopback_xmit() which sets skb->ip_summed to the value
      CHECKSUM_UNNECESSARY, which Herbert's patch teaches us is not
      valid.  So we'll have to address that at some point too.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2626419a
    • J
      udp: fix for unicast RX path optimization · 1223c67c
      Jorge Boncompte [DTI2] 提交于
      Commits 5051ebd2 and
      5051ebd2 ("ipv[46]: udp: optimize unicast RX
      path") broke some programs.
      
      	After upgrading a L2TP server to 2.6.33 it started to fail, tunnels going up an
      down, after the 10th tunnel came up. My modified rp-l2tp uses a global
      unconnected socket bound to (INADDR_ANY, 1701) and one connected socket per
      tunnel after parameter negotiation.
      
      	After ten sockets were open and due to mixed parameters to
      udp[46]_lib_lookup2() kernel started to drop packets.
      Signed-off-by: NJorge Boncompte [DTI2] <jorge@dti2.net>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1223c67c
  2. 08 4月, 2010 11 次提交
  3. 07 4月, 2010 4 次提交
  4. 04 4月, 2010 1 次提交
  5. 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
  6. 02 4月, 2010 15 次提交
  7. 01 4月, 2010 1 次提交
  8. 31 3月, 2010 3 次提交