1. 09 Feb, 2012 12 commits
  2. 08 Feb, 2012 3 commits
  3. 07 Feb, 2012 7 commits
  4. 06 Feb, 2012 9 commits
  5. 05 Feb, 2012 2 commits
    • David Lv's avatar
      via-velocity: S3 resume fix. · b530b193
      David Lv authored
      Initially diagnosed on Ubuntu 11.04 with kernel 2.6.38.
      
      velocity_close is not called during a suspend / resume cycle in this
      driver and it has no business playing directly with power states.
      Signed-off-by: default avatarDavid Lv <DavidLv@viatech.com.cn>
      Acked-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b530b193
    • Julian Anastasov's avatar
      ipv4: reset flowi parameters on route connect · e6b45241
      Julian Anastasov authored
      Eric Dumazet found that commit 813b3b5d
      (ipv4: Use caller's on-stack flowi as-is in output
      route lookups.) that comes in 3.0 added a regression.
      The problem appears to be that resulting flowi4_oif is
      used incorrectly as input parameter to some routing lookups.
      The result is that when connecting to local port without
      listener if the IP address that is used is not on a loopback
      interface we incorrectly assign RTN_UNICAST to the output
      route because no route is matched by oif=lo. The RST packet
      can not be sent immediately by tcp_v4_send_reset because
      it expects RTN_LOCAL.
      
      	So, change ip_route_connect and ip_route_newports to
      update the flowi4 fields that are input parameters because
      we do not want unnecessary binding to oif.
      
      	To make it clear what are the input parameters that
      can be modified during lookup and to show which fields of
      floiw4 are reused add a new function to update the flowi4
      structure: flowi4_update_output.
      
      Thanks to Yurij M. Plotnikov for providing a bug report including a
      program to reproduce the problem.
      
      Thanks to Eric Dumazet for tracking the problem down to
      tcp_v4_send_reset and providing initial fix.
      Reported-by: default avatarYurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6b45241
  6. 04 Feb, 2012 3 commits
  7. 03 Feb, 2012 4 commits
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix kernel panic during driver initilization · 07445f68
      Mohammed Shafi Shajakhan authored
      all works need to be initialized before ieee80211_register_hw
      to prevent mac80211 call backs such as drv_start, drv_config
      getting started. otherwise we would queue/cancel works before
      initializing them and it leads to kernel panic.
      this issue can be recreated with the following script
      in Chrome laptops with AR928X cards, with background scan
      running (or) Network manager is running
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
      	 ---[ end trace 4f86d6139a9900ef ]---
      	 Registered led device: ath9k-phy0
      	 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
      	 irq=16
      	 Kernel panic - not syncing: Fatal exception
      	 Pid: 456, comm: wpa_supplicant Tainted: G      D
      	 3.0.13 #1
      	Call Trace:
      	 [<81379e21>] panic+0x53/0x14a
      	 [<81004a30>] oops_end+0x73/0x81
      	 [<81004b53>] die+0x4c/0x55
      	 [<81002710>] do_trap+0x7c/0x83
      	 [<81002855>] ? do_bounds+0x58/0x58
      	 [<810028cc>] do_invalid_op+0x77/0x81
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
      	 [<8103f809>] ? wait_on_work+0xe2/0xf7
      	 [<8137f807>] error_code+0x67/0x6c
      	 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
      	 [<81040a91>] cancel_work_sync+0xf/0x11
      	 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
      	 [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
      	 [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
      	 [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
      	 [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
      	 [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
      	 [<812dbed8>] __dev_open+0x82/0xab
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      07445f68
    • Amitkumar Karwar's avatar
      mwifiex: handle association failure case correctly · b7097eb7
      Amitkumar Karwar authored
      Currently even if association is failed "iw link" shows some
      information about connected BSS and "Tx timeout" error is seen in
      dmesg log.
      
      This patch fixes below issues in the code to handle assoc failure
      case correctly.
      1) "status" variable in mwifiex_wait_queue_complete() is not
      correctly updated. Hence driver doesn't inform cfg80211 stack
      about association failure.
      2) During association network queues are stopped but carrier is
      not cleared, which gives Tx timeout error in failure case
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b7097eb7
    • John W. Linville's avatar
      ath9k: use WARN_ON_ONCE in ath_rc_get_highest_rix · 8149415e
      John W. Linville authored
      The device seems to survive the issue, so no need to flood the logs
      about it...
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8149415e
    • John W. Linville's avatar
      Merge branch 'master' of... · 157ca9ea
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      157ca9ea