1. 29 Apr, 2011 1 commit
  2. 28 Apr, 2011 3 commits
  3. 20 Apr, 2011 4 commits
  4. 19 Apr, 2011 1 commit
  5. 18 Apr, 2011 5 commits
  6. 13 Apr, 2011 1 commit
  7. 12 Apr, 2011 2 commits
    • Sujith Manoharan's avatar
      ath9k_htc: Fix ethtool reporting · 50f68712
      Sujith Manoharan authored
      Pass the correct module name and device interface so that
      ethtool can display the proper values.
      
      The firmware version will be fixed later on when the FW
      can actually report a version. :)
      Reported-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
      Tested-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50f68712
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
      hardware (before AR9380) after an rx stop has been requested.
      
      This typically shows up in the kernel log with messages like these:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
      Call Trace:
      [<8023f0e8>] dump_stack+0x8/0x34
      [<80075050>] warn_slowpath_common+0x78/0xa4
      [<80075094>] warn_slowpath_null+0x18/0x24
      [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
      [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
      [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
      
      When this happens, the state that the MAC enters is easy to identify and
      does not result in bogus DMA traffic, however to ensure a working state
      after a channel change, the hardware should still be reset.
      
      This patch adds detection for this specific MAC state, after which the above
      warnings completely disappear in my tests.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  8. 11 Apr, 2011 1 commit
  9. 08 Apr, 2011 2 commits
  10. 07 Apr, 2011 3 commits
  11. 04 Apr, 2011 13 commits
  12. 02 Apr, 2011 4 commits
    • Ilpo Järvinen's avatar
      tcp: len check is unnecessarily devastating, change to WARN_ON · 2fceec13
      Ilpo Järvinen authored
      All callers are prepared for alloc failures anyway, so this error
      can safely be boomeranged to the callers domain without super
      bad consequences. ...At worst the connection might go into a state
      where each RTO tries to (unsuccessfully) re-fragment with such
      a mis-sized value and eventually dies.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fceec13
    • Wei Yongjun's avatar
      sctp: malloc enough room for asconf-ack chunk · 2cab86be
      Wei Yongjun authored
      Sometime the ASCONF_ACK parameters can equal to the fourfold of
      ASCONF parameters, this only happend in some special case:
      
        ASCONF parameter is :
          Unrecognized Parameter (4 bytes)
        ASCONF_ACK parameter should be:
          Error Cause Indication parameter (8 bytes header)
           + Error Cause (4 bytes header)
             + Unrecognized Parameter (4bytes)
      
      Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic.
      
      Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs
      EIP: 0060:[<c0717eae>] EFLAGS: 00010246 CPU: 0
      EIP is at skb_put+0x60/0x70
      EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0
      ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000)
      Stack:
       c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40
       c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004
       00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960
      Call Trace:
       [<e1894fa4>] ? sctp_addto_chunk+0x4e/0x89 [sctp]
       [<e1894fa4>] sctp_addto_chunk+0x4e/0x89 [sctp]
       [<e1895a2b>] sctp_process_asconf+0x32f/0x3d1 [sctp]
       [<e188d554>] sctp_sf_do_asconf+0xf8/0x173 [sctp]
       [<e1890b02>] sctp_do_sm+0xb8/0x159 [sctp]
       [<e18a2248>] ? sctp_cname+0x0/0x52 [sctp]
       [<e189392d>] sctp_assoc_bh_rcv+0xac/0xe3 [sctp]
       [<e1897d76>] sctp_inq_push+0x2d/0x30 [sctp]
       [<e18a21b2>] sctp_rcv+0x7a7/0x83d [sctp]
       [<c077a95c>] ? ipv4_confirm+0x118/0x125
       [<c073a970>] ? nf_iterate+0x34/0x62
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c0747992>] ip_local_deliver_finish+0xf5/0x194
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
       [<c0747ab3>] ip_local_deliver+0x3e/0x44
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c074775c>] ip_rcv_finish+0x29f/0x2c7
       [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
       [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
       [<c0747cae>] ip_rcv+0x1f5/0x233
       [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
       [<c071dce3>] __netif_receive_skb+0x310/0x336
       [<c07221f3>] netif_receive_skb+0x4b/0x51
       [<e0a4ed3d>] cp_rx_poll+0x1e7/0x29c [8139cp]
       [<c072275e>] net_rx_action+0x65/0x13a
       [<c0445a54>] __do_softirq+0xa1/0x149
       [<c04459b3>] ? __do_softirq+0x0/0x149
       <IRQ>
       [<c0445891>] ? irq_exit+0x37/0x72
       [<c040a7e9>] ? do_IRQ+0x81/0x95
       [<c07b3670>] ? common_interrupt+0x30/0x38
       [<c0428058>] ? native_safe_halt+0xa/0xc
       [<c040f5d7>] ? default_idle+0x58/0x92
       [<c0408fb0>] ? cpu_idle+0x96/0xb2
       [<c0797989>] ? rest_init+0x5d/0x5f
       [<c09fd90c>] ? start_kernel+0x34b/0x350
       [<c09fd0cb>] ? i386_start_kernel+0xba/0xc1
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cab86be
    • Wei Yongjun's avatar
      sctp: fix auth_hmacs field's length of struct sctp_cookie · 028dba0a
      Wei Yongjun authored
      auth_hmacs field of struct sctp_cookie is used for store
      Requested HMAC Algorithm Parameter, and each HMAC Identifier
      is 2 bytes, so the length should be:
        SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      028dba0a
    • Michał Mirosław's avatar
      net: Fix dev dev_ethtool_get_rx_csum() for forced NETIF_F_RXCSUM · 4dd5ffe4
      Michał Mirosław authored
      dev_ethtool_get_rx_csum() won't report rx checksumming when it's not
      changeable and driver is converted to hw_features and friends. Fix this.
      
      (dev->hw_features & NETIF_F_RXCSUM) check is dropped - if the
      ethtool_ops->get_rx_csum is set, then driver is not coverted, yet.
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd5ffe4