1. 27 Jul, 2009 2 commits
    • reinette chatre's avatar
      iwlagn: fix minimum number of queues setting · 45f5fa32
      reinette chatre authored
      
      
      We need to provide a reasonable minimum that will result in a
      working setup if used. Set minimum to be 10 to provide for
      4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
      4 HT queues (one per AC).
      
      We allow the user to change the number of queues used via a module
      parameter and use this minimum value to check if it is valid. Without
      this patch a user can select a value for the number of queues that
      will result in a failing setup.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Reviewed-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Acked-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      45f5fa32
    • Johannes Berg's avatar
      iwlwifi: fix TX queue race · 3995bd93
      Johannes Berg authored
      
      
      I had a problem on 4965 hardware (well, probably other hardware too,
      but others don't survive my stress testing right now, unfortunately)
      where the driver was sending invalid commands to the device, but no
      such thing could be seen from the driver's point of view. I could
      reproduce this fairly easily by sending multiple TCP streams with
      iperf on different TIDs, though sometimes a single iperf stream was
      sufficient. It even happened with a single core, but I have forced
      preemption turned on.
      
      The culprit was a queue overrun, where we advanced the queue's write
      pointer over the read pointer. After careful analysis I've come to
      the conclusion that the cause is a race condition between iwlwifi
      and mac80211.
      
      mac80211, of course, checks whether the queue is stopped, before
      transmitting a frame. This effectively looks like this:
      
              lock(queues)
              if (stopped(queue)) {
                      unlock(queues)
                      return busy;
      	}
              unlock(queues)
              ...             <-- this place will be important
      			    there is some more code here
              drv_tx(frame)
      
      The driver, on the other hand, can stop and start queues, which does
      
              lock(queues)
              mark_running/stopped(queue)
              unlock(queues)
      
      	[if marked running: wake up tasklet to send pending frames]
      
      Now, however, once the driver starts the queue, mac80211 can see that
      and end up at the marked place above, at which point for some reason the
      driver seems to stop the queue again (I don't understand that) and then
      we end up transmitting while the queue is actually full.
      
      Now, this shouldn't actually matter much, but for some reason I've seen
      it happen multiple times in a row and the queue actually overflows, at
      which point the queue bites itself in the tail and things go completely
      wrong.
      
      This patch fixes this by just dropping the packet should this have
      happened, and making the lock in iwlwifi cover everything so iwlwifi
      can't race against itself (dropping the lock there might make it more
      likely, but it did seem to happen without that too).
      
      Since we can't hold the lock across drv_tx() above, I see no way to fix
      this in mac80211, but I also don't understand why I haven't seen this
      before -- maybe I just never stress tested it this badly.
      
      With this patch, the device has survived many minutes of simultanously
      sending two iperf streams on different TIDs with combined throughput
      of about 60 Mbps.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3995bd93
  2. 21 Jul, 2009 2 commits
  3. 15 Jun, 2009 5 commits
  4. 12 Jun, 2009 1 commit
  5. 10 Jun, 2009 1 commit
  6. 04 Jun, 2009 6 commits
  7. 03 Jun, 2009 4 commits
    • Johannes Berg's avatar
      rfkill: rewrite · 19d337df
      Johannes Berg authored
      
      
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19d337df
    • Rami Rosen's avatar
      iwlwifi: avoid build warning in iwl-core. · d651ae32
      Rami Rosen authored
      
      
      When building when CONFIG_IWLWIFI_DEBUG is not set, we get the following
      warning:
      /work/src/w/drivers/net/wireless/iwlwifi/iwl-core.c: In function ‘iwl_isr’:
      /work/src/w/drivers/net/wireless/iwlwifi/iwl-core.c:1707: warning:
      unused variable ‘inta_fh’
      
      This patch avoids this warning by adding #ifdef CONFIG_IWLWIFI_DEBUG
      before the declaration of inta_fh in iwl_isr() in
      drivers/net/wireless/iwlwifi/iwl-core.c
      Signed-off-by: default avatarRami Rosen <ramirose@gmail.com>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d651ae32
    • Reinette Chatre's avatar
      iwlwifi: fix otp access init · d77b034f
      Reinette Chatre authored
      
      
      Polling function returns positive time if polling was needed to
      read value. This is still success.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      CC: Wey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d77b034f
    • Reinette Chatre's avatar
      iwlwifi: fix merge error · df29ff37
      Reinette Chatre authored
      This hunk of code was removed in patch "iwlwifi: do not
      cancel delayed work inside spin_lock_irqsave" submitted at
      http://marc.info/?l=linux-wireless&m=124267503030042&w=2
      
      
      
      This same patch in this repo does not remove this hunk.
      Remove it here.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      df29ff37
  8. 22 May, 2009 13 commits
  9. 20 May, 2009 6 commits