1. 17 Apr, 2009 2 commits
  2. 16 Apr, 2009 5 commits
    • Gerrit Renker's avatar
      mac80211: Fragmentation threshold (typo) · 23a99840
      Gerrit Renker authored
      
      
      mac80211: Fragmentation threshold (typo)
      
      ieee80211_ioctl_siwfrag() sets the fragmentation_threshold to 2352
      when frame fragmentation is to be disabled, yet the corresponding
      'get' function tests for 2353 bytes instead.
      
      This causes user-space tools to display a fragmentation threshold
      of 2352 bytes even if fragmentation has been disabled.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      23a99840
    • Michael Buesch's avatar
      mac80211: quiet beacon loss messages · a860402d
      Michael Buesch authored
      
      
      On Sunday 05 April 2009 11:29:38 Michael Buesch wrote:
      > On Sunday 05 April 2009 11:23:59 Jaswinder Singh Rajput wrote:
      > > With latest linus tree I am getting, .config file attached:
      > >
      > > [   22.895051] r8169: eth0: link down
      > > [   22.897564] ADDRCONF(NETDEV_UP): eth0: link is not ready
      > > [   22.928047] ADDRCONF(NETDEV_UP): wlan0: link is not ready
      > > [   22.982292] libvirtd used greatest stack depth: 4200 bytes left
      > > [   63.709879] wlan0: authenticate with AP 00:11:95:9e:df:f6
      > > [   63.712096] wlan0: authenticated
      > > [   63.712127] wlan0: associate with AP 00:11:95:9e:df:f6
      > > [   63.726831] wlan0: RX AssocResp from 00:11:95:9e:df:f6 (capab=0x471 status=0 aid=1)
      > > [   63.726855] wlan0: associated
      > > [   63.730093] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
      > > [   74.296087] wlan0: no IPv6 routers present
      > > [   79.349044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  119.358200] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  179.354292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  259.366044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  359.348292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  361.953459] packagekitd used greatest stack depth: 4160 bytes left
      > > [  478.824258] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  598.813343] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  718.817292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  838.824567] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  958.815402] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1078.848434] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1198.822913] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1318.824931] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1438.814157] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1558.827336] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1678.823011] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1798.830589] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1918.828044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2038.827224] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2116.517152] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2158.840243] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2278.827427] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      >
      >
      > I think this message should only show if CONFIG_MAC80211_VERBOSE_DEBUG is set.
      > It's kind of expected that we lose a beacon once in a while, so we shouldn't print
      > verbose messages to the kernel log (even if they are KERN_DEBUG).
      >
      > And besides that, I think one can easily remotely trigger this message and flood the logs.
      > So it should probably _also_ be ratelimited.
      
      Something like this:
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      a860402d
    • Johannes Berg's avatar
      mac80211: correct wext transmit power handler · 47afbaf5
      Johannes Berg authored
      Wext makes no assumptions about the contents of
      data->txpower.fixed and data->txpower.value when
      data->txpower.disabled is set, so do not update
      the user-requested power level while disabling.
      
      Also, when wext configures a really _fixed_ power
      output [1], we should reject it instead of limiting it
      to the regulatory constraint. If the user wants to set
      a _limit_ [2] then we should honour that.
      
      [1] iwconfig wlan0 txpower 20dBm fixed
      [2] iwconfig wlan0 txpower 10dBm
      
      This fixes
      http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1942
      
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      47afbaf5
    • Vasanthakumar Thiagarajan's avatar
      mac80211: Fix bug in getting rx status for frames pending in reorder buffer · b3631286
      Vasanthakumar Thiagarajan authored
      
      
      Currently rx status for frames which are completed from reorder buffer
      is taken from it's cb area which is not always right, cb is not holding
      the rx status when driver uses mac80211's non-irq rx handler to pass it's
      received frames. This results in dropping almost all frames from reorder
      buffer when security is enabled by doing double decryption (first in hw,
      second in sw because of wrong rx status). This patch copies rx status into
      cb area before the frame is put into reorder buffer. After this patch,
      there is a significant improvement in throughput with ath9k + WPA2(AES).
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b3631286
    • Luis R. Rodriguez's avatar
      cfg80211: fix NULL pointer deference in reg_device_remove() · 0ad8acaf
      Luis R. Rodriguez authored
      
      
      We won't ever get here as regulatory_hint_core() can only fail
      on -ENOMEM and in that case we don't initialize cfg80211 but this is
      technically correct code.
      
      This is actually good for stable, where we don't check for -ENOMEM
      failure on __regulatory_hint()'s failure.
      
      Cc: stable@kernel.org
      Reported-by: default avatarQuentin Armitage <Quentin@armitage.org.uk>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0ad8acaf
  3. 15 Apr, 2009 1 commit
    • Eric Dumazet's avatar
      packet: avoid warnings when high-order page allocation fails · 719bfeaa
      Eric Dumazet authored
      
      
      Latest tcpdump/libpcap triggers annoying messages because of high order page
      allocation failures (when lowmem exhausted or fragmented)
      
      These allocation errors are correctly handled so could be silent.
      
      [22660.208901] tcpdump: page allocation failure. order:5, mode:0xc0d0
      [22660.208921] Pid: 13866, comm: tcpdump Not tainted 2.6.30-rc2 #170
      [22660.208936] Call Trace:
      [22660.208950]  [<c04e2b46>] ? printk+0x18/0x1a
      [22660.208965]  [<c02760f7>] __alloc_pages_internal+0x357/0x460
      [22660.208980]  [<c0276251>] __get_free_pages+0x21/0x40
      [22660.208995]  [<c04cc835>] packet_set_ring+0x105/0x3d0
      [22660.209009]  [<c04ccd1d>] packet_setsockopt+0x21d/0x4d0
      [22660.209025]  [<c0270400>] ? filemap_fault+0x0/0x450
      [22660.209040]  [<c0449e34>] sys_setsockopt+0x54/0xa0
      [22660.209053]  [<c044b97f>] sys_socketcall+0xef/0x270
      [22660.209067]  [<c0202e34>] sysenter_do_call+0x12/0x26
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      719bfeaa
  4. 14 Apr, 2009 4 commits
  5. 13 Apr, 2009 2 commits
  6. 11 Apr, 2009 3 commits
  7. 06 Apr, 2009 5 commits
  8. 04 Apr, 2009 1 commit
    • Eric Dumazet's avatar
      socket: use percpu_add() while updating sockets_in_use · 4e69489a
      Eric Dumazet authored
      
      
      sock_alloc() currently uses following code to update sockets_in_use
      
      get_cpu_var(sockets_in_use)++;
      put_cpu_var(sockets_in_use);
      
      This translates to :
      
      c0436274:       b8 01 00 00 00          mov    $0x1,%eax
      c0436279:       e8 42 40 df ff          call   c022a2c0 <add_preempt_count>
      c043627e:       bb 20 4f 6a c0          mov    $0xc06a4f20,%ebx
      c0436283:       e8 18 ca f0 ff          call   c0342ca0 <debug_smp_processor_id>
      c0436288:       03 1c 85 60 4a 65 c0    add    -0x3f9ab5a0(,%eax,4),%ebx
      c043628f:       ff 03                   incl   (%ebx)
      c0436291:       b8 01 00 00 00          mov    $0x1,%eax
      c0436296:       e8 75 3f df ff          call   c022a210 <sub_preempt_count>
      c043629b:       89 e0                   mov    %esp,%eax
      c043629d:       25 00 e0 ff ff          and    $0xffffe000,%eax
      c04362a2:       f6 40 08 08             testb  $0x8,0x8(%eax)
      c04362a6:       75 07                   jne    c04362af <sock_alloc+0x7f>
      c04362a8:       8d 46 d8                lea    -0x28(%esi),%eax
      c04362ab:       5b                      pop    %ebx
      c04362ac:       5e                      pop    %esi
      c04362ad:       c9                      leave
      c04362ae:       c3                      ret
      c04362af:       e8 cc 5d 09 00          call   c04cc080 <preempt_schedule>
      c04362b4:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
      c04362b8:       eb ee                   jmp    c04362a8 <sock_alloc+0x78>
      
      While percpu_add(sockets_in_use, 1) translates to a single instruction :
      
      c0436275:   64 83 05 20 5f 6a c0    addl   $0x1,%fs:0xc06a5f20
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e69489a
  9. 03 Apr, 2009 1 commit
  10. 02 Apr, 2009 7 commits
  11. 01 Apr, 2009 4 commits
  12. 31 Mar, 2009 3 commits
  13. 30 Mar, 2009 2 commits