1. 02 May, 2009 2 commits
  2. 01 May, 2009 12 commits
  3. 30 Apr, 2009 1 commit
  4. 29 Apr, 2009 5 commits
    • Lennert Buytenhek's avatar
      mv643xx_eth: 64bit mib counter read fix · 93af7aca
      Lennert Buytenhek authored
      On several mv643xx_eth hardware versions, the two 64bit mib counters
      for 'good octets received' and 'good octets sent' are actually 32bit
      counters, and reading from the upper half of the register has the same
      effect as reading from the lower half of the register: an atomic
      read-and-clear of the entire 32bit counter value.  This can under heavy
      traffic occasionally lead to small numbers being added to the upper
      half of the 64bit mib counter even though no 32bit wrap has occured.
      Since we poll the mib counters at least every 30 seconds anyway, we
      might as well just skip the reads of the upper halves of the hardware
      counters without breaking the stats, which this patch does.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Lennert Buytenhek's avatar
      mv643xx_eth: OOM handling fixes · 1319ebad
      Lennert Buytenhek authored
      Currently, when OOM occurs during rx ring refill, mv643xx_eth will get
      into an infinite loop, due to the refill function setting the OOM bit
      but not clearing the 'rx refill needed' bit for this queue, while the
      calling function (the NAPI poll handler) will call the refill function
      in a loop until the 'rx refill needed' bit goes off, without checking
      the OOM bit.
      This patch fixes this by checking the OOM bit in the NAPI poll handler
      before attempting to do rx refill.  This means that once OOM occurs,
      we won't try to do any memory allocations again until the next invocation
      of the poll handler.
      While we're at it, change the OOM flag to be a single bit instead of
      one bit per receive queue since OOM is a system state rather than a
      per-queue state, and cancel the OOM timer on entry to the NAPI poll
      handler if it's running to prevent it from firing when we've already
      come out of OOM.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
    • Johannes Berg's avatar
      mac80211: default to automatic power control · c428c892
      Johannes Berg authored
      In "mac80211: correct wext transmit power handler"
      I fixed the wext handler, but forgot to make the default of the
      user_power_level -1 (aka "auto"), so that now the transmit power
      is always set to 0, causing associations to time out and similar
      problems since we're transmitting with very little power. Correct
      this by correcting the default user_power_level to -1.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Bisected-by: default avatarNiel Lambrechts <niel.lambrechts@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Alan Jenkins's avatar
      mac80211: fix modprobe deadlock by not calling wep_init under rtnl_lock · d4c4a9a1
      Alan Jenkins authored
      - ieee80211_wep_init(), which is called with rtnl_lock held, blocks in
         request_module() [waiting for modprobe to load a crypto module].
       - modprobe blocks in a call to flush_workqueue(), when it closes a TTY
         [presumably when it exits].
       - The workqueue item linkwatch_event() blocks on rtnl_lock.
      There's no reason for wep_init() to be called with rtnl_lock held, so
      just move it outside the critical section.
      Signed-off-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 28 Apr, 2009 11 commits
    • Thadeu Lima de Souza Cascardo's avatar
      e100: do not go D3 in shutdown unless system is powering off · ac7c992c
      Thadeu Lima de Souza Cascardo authored
      After experimenting with kexec with the last merges after 2.6.29, I've
      had some problems when probing e100.  It would not read the eeprom.  After
      some bisects, I realized this has been like that since forever (at least
      2.6.18).  The problem is that shutdown is doing the same thing that
      suspend does and puts the device in D3 state.  I couldn't find a way to
      get the device back to a sane state in the probe function.  So, based on
      some similar patches from Rafael J. Wysocki for e1000, e1000e, and ixgbe,
      I wrote this one for e100.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Acked-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
    • Stephen Hemminger's avatar
      netfilter: revised locking for x_tables · 942e4a2b
      Stephen Hemminger authored
      The x_tables are organized with a table structure and a per-cpu copies
      of the counters and rules. On older kernels there was a reader/writer 
      lock per table which was a performance bottleneck. In 2.6.30-rc, this
      was converted to use RCU and the counters/rules which solved the performance
      problems for do_table but made replacing rules much slower because of
      the necessary RCU grace period.
      This version uses a per-cpu set of spinlocks and counters to allow to
      table processing to proceed without the cache thrashing of a global
      reader lock and keeps the same performance for table updates.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Bob Copeland's avatar
      ath5k: fix buffer overrun in rate debug code · b7fcb5c4
      Bob Copeland authored
      char bname[5] is too small for the string "X GHz" when the null
      terminator is taken into account.  Thus, turning on rate debugging
      can crash unless we have lucky stack alignment.
      Cc: stable@kernel.org
      Reported-by: default avatarParide Legovini <legovini@spiro.fisica.unipd.it>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      iwlwifi: notify on scan completion even when shutting down · 74aa9be0
      Johannes Berg authored
      Under certain circumstances iwlwifi can get stuck and will no
      longer accept scan requests, because the core code (cfg80211)
      thinks that it's still processing one. This fixes one of the
      points where it can happen, but I've still seen it (although
      only with my radio-off-when-idle patch).
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Jussi Kivilinna's avatar
      rndis_wlan: fix initialization order for workqueue&workers · e805e4d0
      Jussi Kivilinna authored
      rndis_wext_link_change() might be called from rndis_command() at
      initialization stage and priv->workqueue/priv->work have not been
      initialized yet. This causes invalid opcode at rndis_wext_bind on
      some brands of bcm4320.
      Fix by initializing workqueue/workers in rndis_wext_bind() before
      rndis_command is used.
      This bug has existed since 2.6.25, reported at:
      	http://bugzilla.kernel.org/show_bug.cgi?id=12794Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Stephen Rothwell's avatar
      wireless: remove unneeded EXPORT_SYMBOL the tickles a powerpc compiler bug · 6269b731
      Stephen Rothwell authored
      drivers/net/wireless/iwlwifi/iwl3945-base.c:1415: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict
      I am pretty sure that this is a compiler bug, so not to worry.  However,
      as far as I can see, iwl-3945.o (the only user) and iwl3945-base.o are
      always linked into the same module, so the EXPORT_SYMBOL (which causes
      the problem) should not be needed.  Correct?
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Roger Quadros's avatar
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros authored
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      It eliminates the following error on a preemptible kernel:
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Eric Dumazet's avatar
      net: Avoid extra wakeups of threads blocked in wait_for_packet() · bf368e4e
      Eric Dumazet authored
      In 2.6.25 we added UDP mem accounting.
      This unfortunatly added a penalty when a frame is transmitted, since
      we have at TX completion time to call sock_wfree() to perform necessary
      memory accounting. This calls sock_def_write_space() and utimately
      scheduler if any thread is waiting on the socket.
      Thread(s) waiting for an incoming frame was scheduled, then had to sleep
      again as event was meaningless.
      (All threads waiting on a socket are using same sk_sleep anchor)
      This adds lot of extra wakeups and increases latencies, as noted
      by Christoph Lameter, and slows down softirq handler.
      Reference : http://marc.info/?l=linux-netdev&m=124060437012283&w=2 
      Fortunatly, Davide Libenzi recently added concept of keyed wakeups
      into kernel, and particularly for sockets (see commit
      epoll keyed wakeups: make sockets use keyed wakeups)
      Davide goal was to optimize epoll, but this new wakeup infrastructure
      can help non epoll users as well, if they care to setup an appropriate
      This patch introduces new DEFINE_WAIT_FUNC() helper and uses it
      in wait_for_packet(), so that only relevant event can wakeup a thread
      blocked in this function.
      Trace of function calls from bnx2 TX completion bnx2_poll_work() is :
            receiver_wake_function() : Stops here since thread is waiting for an INPUT
      Reported-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 27 Apr, 2009 9 commits