1. 21 Nov, 2008 34 commits
  2. 18 Nov, 2008 3 commits
    • Johannes Berg's avatar
      iwlagn: fix RX skb alignment · 4018517a
      Johannes Berg authored
      So I dug deeper into the DMA problems I had with iwlagn and a kind soul
      helped me in that he said something about pci-e alignment and mentioned
      the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
      there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
      something the device would fail with, but when I looked into the
      function for a minute anyway I stumbled over this little gem:
      
      	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));
      
      Clearly, that is a totally bogus check, one would hope the compiler
      removes it entirely. (Think about it)
      
      After fixing it, I obviously ran into it, nothing guarantees the
      alignment the way you want it,  because of the way skbs and their
      headroom are allocated. I won't explain that here nor double-check that
      I'm right, that goes beyond what most of the CC'ed people care about.
      
      So then I came up with the patch below, and so far my system has
      survived minutes with 64K pages, when it would previously fail in
      seconds. And I haven't seen a single instance of the TX bug either. But
      when you see the patch it'll be pretty obvious to you why.
      
      This should fix the following reported kernel bugs:
      
      http://bugzilla.kernel.org/show_bug.cgi?id=11596
      http://bugzilla.kernel.org/show_bug.cgi?id=11393
      http://bugzilla.kernel.org/show_bug.cgi?id=11983
      
      
      
      I haven't checked if there are any elsewhere, but I suppose RHBZ will
      have a few instances too...
      
      I'd like to ask anyone who is CC'ed (those are people I know ran into
      the bug) to try this patch.
      
      I am convinced that this patch is correct in spirit, but I haven't
      understood why, for example, there are so many unmap calls. I'm not
      entirely convinced that this is the only bug leading to the TX reply
      errors.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4018517a
    • Johannes Berg's avatar
      mac80211: remove ieee80211_notify_mac · 8e3bad65
      Johannes Berg authored
      Before ieee80211_notify_mac() was added, it was presented with the
      use case of using it to tell mac80211 that the association may
      have been lost because the firmware crashed/reset.
      
      Since then, it has also been used by iwlwifi to (slightly) speed
      up re-association after resume, a workaround around the fact that
      mac80211 has no suspend/resume handling yet. It is also not used
      by any other drivers, so clearly it cannot be necessary for "good
      enough" suspend/resume.
      
      Unfortunately, the callback suffers from a severe problem: It only
      works for station mode. If suspend/resume happens while in IBSS or
      any other mode (but station), then the callback is pointless.
      
      Recently, it has created a number of locking issues, first because
      it required rtnl locking rather than RCU due to calling sleeping
      functions within the critical section, and now because it's called
      by iwlwifi from the mac80211 workqueue that may not use the rtnl
      because it is flushed under rtnl.
      (cf. http://bugzilla.kernel.org/show_bug.cgi?id=12046
      
      )
      
      I think, therefore, that we should take a step back, remove it
      entirely for now and add the small feature it provided properly.
      For suspend and resume we will need to introduce new hooks, and for
      the case where the firmware was reset the driver will probably
      simply just pretend it has done a suspend/resume cycle to get
      mac80211 to reprogram the hardware completely, not just try to
      connect to the current AP again in station mode. When doing so, we
      will need to take into account locking issues and possibly defer
      to schedule_work from within mac80211 for the resume operation,
      while the suspend operation must be done directly.
      
      Proper suspend/resume should also not necessarily try to reconnect
      to the current AP, the time spent in suspend may have been short
      enough to not be disconnected from the AP, mac80211 will detect
      that the AP went out of range quickly if it did, and if the
      association is lost then the AP will disassoc as soon as a data
      frame is sent. We might also take into account WWOL then, and
      have mac80211 program the hardware into such a mode where it is
      available and requested.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8e3bad65
    • Johannes Berg's avatar
      libertas_tf: fix skb tail pointer · 9b44fb89
      Johannes Berg authored
      
      
      skb->tail can't be meant here because it's not the same across 32/64 bit
      compilations. This means there's no way the current driver can work on
      64-bit architectures.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org [2.6.27]
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9b44fb89
  3. 13 Nov, 2008 2 commits
    • Wang Chen's avatar
      netdevice: safe convert to netdev_priv() #part-4 · 524ad0a7
      Wang Chen authored
      
      
      We have some reasons to kill netdev->priv:
      1. netdev->priv is equal to netdev_priv().
      2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
         netdev_priv() is more flexible than netdev->priv.
      But we cann't kill netdev->priv, because so many drivers reference to it
      directly.
      
      This patch is a safe convert for netdev->priv to netdev_priv(netdev).
      Since all of the netdev->priv is only for read.
      But it is too big to be sent in one mail.
      I split it to 4 parts and make every part smaller than 100,000 bytes,
      which is max size allowed by vger.
      Signed-off-by: default avatarWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      524ad0a7
    • Wang Chen's avatar
      netdevice: safe convert to netdev_priv() #part-3 · 8f15ea42
      Wang Chen authored
      
      
      We have some reasons to kill netdev->priv:
      1. netdev->priv is equal to netdev_priv().
      2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
         netdev_priv() is more flexible than netdev->priv.
      But we cann't kill netdev->priv, because so many drivers reference to it
      directly.
      
      This patch is a safe convert for netdev->priv to netdev_priv(netdev).
      Since all of the netdev->priv is only for read.
      But it is too big to be sent in one mail.
      I split it to 4 parts and make every part smaller than 100,000 bytes,
      which is max size allowed by vger.
      Signed-off-by: default avatarWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f15ea42
  4. 12 Nov, 2008 1 commit
    • Johannes Berg's avatar
      hostap: pad the skb->cb usage in lieu of a proper fix · f7cd1686
      Johannes Berg authored
      
      
      Like mac80211 did, this driver makes 'clever' use of skb->cb to pass
      information along with an skb as it is requeued from the virtual device
      to the physical wireless device.  Unfortunately, that trick no longer
      works...
      
      Unlike mac80211, code complexity and driver apathy makes this hack
      the best option we have in the short run.  Hopefully someone will
      eventually be motivated to code a proper fix before all the effected
      hardware dies.
      
      (Above text by me.  Johannes officially disavows all knowledge of this
      hack. -- JWL)
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f7cd1686