1. 08 May, 2013 19 commits
  2. 07 May, 2013 2 commits
  3. 06 May, 2013 2 commits
  4. 05 May, 2013 1 commit
  5. 04 May, 2013 1 commit
  6. 03 May, 2013 7 commits
    • Thadeu Lima de Souza Cascardo's avatar
      cxgb4: fix error recovery when t4_fw_hello returns a positive value · 777c2300
      Thadeu Lima de Souza Cascardo authored
      Since commit 636f9d37
      
       ("cxgb4: Add
      support for T4 configuration file"), t4_fw_hello may return a positive
      value instead of 0 for success. The recovery code tests only for zero
      and fails recovery for any other value.
      
      This fix tests for negative error values and fails only on those cases.
      Error recovery after an error injection works after this change.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      777c2300
    • Kirill Smelkov's avatar
      sky2: Fix crash on receiving VLAN frames · 88dccf5b
      Kirill Smelkov authored
      After recent 86a9bad3 (net: vlan: add protocol argument to packet
      tagging functions) my sky2 started to crash on receive of tagged
      frames, with backtrace similar to
      
          #CRASH!!!
          vlan_do_receive
          __netif_receive_skb_core
          __netif_receive_skb
          netif_receive_skb
          sky2_poll
          ...
          __net_rx_action
          __do_softirq
      
      The problem turned out to be:
      
          1) sky2 copies small packets from ring on RX, and in its
             receive_copy() skb header is copied manually field, by field, and
             only for some fields;
      
          2) 86a9bad3  added skb->vlan_proto, which vlan_untag() or
             __vlan_hwaccel_put_tag() set, and which is later used in
             vlan_do_receive().
      
             That patch updated copy_skb_header() for newly introduced
             skb->vlan_proto, but overlooked the need to also copy it in sky2's
             receive_copy().
      
      Because of 2, we have the following scenario:
      
          - frame is received and tagged in a ring, by sky2_rx_tag(). Both
            skb->vlan_proto and skb->vlan_tci are set;
      
          - later skb is decided to be copied, but skb->vlan_proto is
            forgotten and becomes 0.
      
          - in the beginning of vlan_do_receive() we call
      
              __be16 vlan_proto = skb->vlan_proto;
              vlan_dev = vlan_find_dev(skb->dev, vlan_proto, vlan_id);
      
            which eventually invokes
      
              vlan_proto_idx(vlan_proto)
      
            and that routine BUGs for everything except ETH_P_8021Q and
            ETH_P_8021AD.
      
            Oops.
      
      Fix it.
      
      P.S.
      
      Stephen, I wonder, why copy_skb_header() is not used in
      sky2.c::receive_copy() ? Problems, where receive_copy was updated field
      by field showed several times already, e.g.
      
          3f42941b    (sky2: propogate rx hash when packet is copied)
          e072b3fa
      
          (sky2: fix receive length error in mixed non-VLAN/VLAN traffic)
      
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Signed-off-by: default avatarKirill Smelkov <kirr@mns.spb.ru>
      Acked-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88dccf5b
    • holger@eitzenberger.org's avatar
      asix: fix BUG in receive path when lowering MTU · c5060cec
      holger@eitzenberger.org authored
      
      
      There is bug in the receive path of the asix driver at the time a
      packet is received larger than MTU size and DF bit set:
      
       BUG: unable to handle kernel paging request at 0000004000000001
       IP: [<ffffffff8126f65b>] skb_release_head_state+0x2d/0xd2
       ...
       Call Trace:
        <IRQ>
        [<ffffffff8126f86d>] ? skb_release_all+0x9/0x1e
        [<ffffffff8126f8ad>] ? __kfree_skb+0x9/0x6f
        [<ffffffffa00b4200>] ? asix_rx_fixup_internal+0xff/0x1ae [asix]
        [<ffffffffa00fb3dc>] ? usbnet_bh+0x4f/0x226 [usbnet]
        ...
      
      It is easily reproducable by setting an MTU of 512 e. g. and sending
      something like
      
        ping -s 1472 -c 1 -M do $SELF
      
      from another box.
      
      And this is because the rx->ax_skb is freed on error, but rx->ax_skb
      is not reset, and the size is not reset to zero in this case.
      
      And since the skb is added again to the usbnet->done skb queue it is
      accessing already freed memory, resulting in the BUG when freeing a
      2nd time.  I therefore think the value 0x0000004000000001 show in the
      trace is more or less random data.
      Signed-off-by: default avatarHolger Eitzenberger <holger@eitzenberger.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5060cec
    • Teppo Kotilainen's avatar
      net: qmi_wwan: Add Telewell TW-LTE 4G · 0decc64b
      Teppo Kotilainen authored
      
      
      Information from driver description files:
      
        diag:  VID_19D2&PID_0412&MI_00
        nmea:  VID_19D2&PID_0412&MI_01
        at:    VID_19D2&PID_0412&MI_02
        modem: VID_19D2&PID_0412&MI_03
        net:   VID_19D2&PID_0412&MI_04
      Signed-off-by: default avatarTeppo Kotilainen <qubit303@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0decc64b
    • Dan Carpenter's avatar
      usbnet: pegasus: endian bug in write_mii_word() · 3d64fc70
      Dan Carpenter authored
      
      
      We're only passing the two high bytes of an integer.  It works for
      little endian but not for big endian.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d64fc70
    • Stanislaw Gruszka's avatar
      ath5k: do not reschedule tx_complete_work on stop · db178340
      Stanislaw Gruszka authored
      This patch claim to fix "WARNING: at net/mac80211/util.c:599
      ieee80211_can_queue_work.isra.7+0x30/0x40", which was reported at:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=922295
      
      
      
      We use ATH_STAT_STARTED flag to disallow to perform
      ath5k_tx_complete_poll_work() code, hence reschedule
      ah->tx_complete_work, when we stop device. This flag was defined in
      ath5k code, but it was not used.
      
      I didn't get feedback if the fix works, so patch is compile only tested.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      db178340
    • Felix Fietkau's avatar
      ath9k: fix key allocation error handling for powersave keys · 4ef69d03
      Felix Fietkau authored
      
      
      If no keycache slots are available, ath_key_config can return -ENOSPC.
      If the key index is not checked for errors, it can lead to logspam that
      looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range"
      This can cause follow-up errors if the invalid keycache index gets
      used for tx.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4ef69d03
  7. 02 May, 2013 8 commits