1. 16 Jan, 2009 11 commits
    • Artur Skawina's avatar
      p54: set_tim must be atomic. · 27571908
      Artur Skawina authored
      Fix for:
      
      BUG: scheduling while atomic: named/2004/0x10000200
      Pid: 2004, comm: named Not tainted 2.6.29-rc1-00271-ge9fa6b0 #45
      Call Trace:
       [<c04d4ef7>] schedule+0x2a7/0x320
       [<c03aed74>] __alloc_skb+0x34/0x110
       [<c011f5b3>] __cond_resched+0x13/0x30
       [<c04d501d>] _cond_resched+0x2d/0x40
       [<c016d8c5>] kmem_cache_alloc+0x95/0xc0
       [<c016b8d4>] check_object+0xc4/0x230
       [<c03aed74>] __alloc_skb+0x34/0x110
       [<c02ede91>] p54_alloc_skb+0x71/0xf0
       [<c02ee36f>] p54_set_tim+0x3f/0xa0
       [<c04ae064>] sta_info_set_tim_bit+0x64/0x80
       [<c04c1017>] invoke_tx_handlers+0xd57/0xd80
       [<c016c397>] free_debug_processing+0x197/0x210
       [<c03ae215>] pskb_expand_head+0xf5/0x170
       [<c04bfd94>] __ieee80211_tx_prepare+0x164/0x2f0
       [<c04c1a8d>] ieee80211_skb_resize+0x6d/0xe0
       [<c04c250f>] ieee80211_master_start_xmit+0x23f/0x550
       [<c016d188>] __slab_alloc+0x2b8/0x4f0
       [<c013a711>] getnstimeofday+0x51/0x120
       [<c03b5e7b>] dev_hard_start_xmit+0x1db/0x240
       [<c03c6a4b>] __qdisc_run+0x1ab/0x200
       [<c0136aa1>] __run_hrtimer+0x31/0xf0
       [<c03b6247>] dev_queue_xmit+0x247/0x500
       [<c04c1e56>] ieee80211_subif_start_xmit+0x356/0x7d0
       [<c0466ff7>] packet_rcv_spkt+0x37/0x150
       [<c0466ff7>] packet_rcv_spkt+0x37/0x150
       [<c03b5e7b>] dev_hard_start_xmit+0x1db/0x240
       [<c03c6a4b>] __qdisc_run+0x1ab/0x200
       [<c03b6247>] dev_queue_xmit+0x247/0x500
       [<c03bc1e2>] neigh_resolve_output+0xe2/0x200
       [<c0410080>] ip_finish_output+0x0/0x290
       [<c0410267>] ip_finish_output+0x1e7/0x290
       [<c040f355>] ip_local_out+0x15/0x20
       [<c040f5d2>] ip_push_pending_frames+0x272/0x380
       [<c042bbc6>] udp_push_pending_frames+0x146/0x3a0
       [<c042d52a>] udp_sendmsg+0x2fa/0x6b0
       [<c0433bc7>] inet_sendmsg+0x37/0x70
       [<c03a7b7e>] sock_sendmsg+0xbe/0x100
       [<c0133cd0>] autoremove_wake_function+0x0/0x50
       [<c011c043>] __wake_up_common+0x43/0x70
       [<c024a892>] copy_from_user+0x32/0x130
       [<c024a892>] copy_from_user+0x32/0x130
       [<c03b001e>] verify_iovec+0x2e/0xb0
       [<c03a7d3f>] sys_sendmsg+0x17f/0x290
       [<c017730a>] pipe_write+0x29a/0x570
       [<c013a172>] update_wall_time+0x492/0x8e0
       [<c013a711>] getnstimeofday+0x51/0x120
       [<c011b05d>] sched_slice+0x3d/0x80
       [<c013a711>] getnstimeofday+0x51/0x120
       [<c0136657>] hrtimer_forward+0x147/0x1a0
       [<c01101b0>] lapic_next_event+0x10/0x20
       [<c013ccb3>] clockevents_program_event+0xa3/0x170
       [<c03a9054>] sys_socketcall+0xa4/0x290
       [<c0110920>] smp_apic_timer_interrupt+0x40/0x70
       [<c0103165>] sysenter_do_call+0x12/0x25
      Signed-off-by: default avatarArtur Skawina <art.08.09@gmail.com>
      Acked-by: default avatarChristian Lamparter <chunkeey@web.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      27571908
    • Rami Rosen's avatar
      rt2x00: fix a wrong parameter for __test_and_clear_bit() in rt2x00rfkill_free(). · e223b6dc
      Rami Rosen authored
      When running modprobe rt73usb, and then rmmod rt73usb, and then
      iwconfig, the wlan0 device does not disappear. When repeating this
      process again, we get a kernel Oops errors and "BUG: unable to handle
      kernel paging request..." message in the kernel log.
      
      The reason for this is that there is an error in rt2x00rfkill_free(),
      which is called in the process of removing the device
      (rt2x00lib_remove_dev() in rt2x00dev.c).
      rt2x00rfkill_free() clears the RFKILL_STATE_ALLOCATED bit , which is
      bit number 1 () in rt2x00dev->flags instead of in
      rt2x00dev->rfkill_state. As a result, when checking the
      DEVICE_STATE_REGISTERED_HW bit (bit number 1 in rt2x00dev->flags) in
      rt2x00lib_remove_hw() it is **unset**, and we wrongly **don't** call
      ieee80211_unregister_hw().
      
      This patch corrects this: the parameter for __test_and_clear_bit() in
      rt2x00rfkill_free() should be &rt2x00dev->rfkill_state and not
      &rt2x00dev->flags.
      Signed-off-by: default avatarRami Rosen <ramirose@gmail.com>
      Acked-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e223b6dc
    • Luis R. Rodriguez's avatar
      cfg80211: Fix parsed country IE info for 5 GHz · 02e68a3d
      Luis R. Rodriguez authored
      The country IE number of channels on 5 GHz specifies the number
      of 5 GHz channels, not the number of sequential channel numbers.
      For example, if in a country IEs if the first channel given is 36
      and the number of channels passed is 4 then the individual channel
      numbers defined for the 5 GHz PHY by these parameters
      
      are: 36, 40, 44, 48
      not: 36, 37, 38, 39
      
      See: http://tinyurl.com/11d-clarificationSigned-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      02e68a3d
    • Luis R. Rodriguez's avatar
      cfg80211: Fix regression with 11d on bands · 0c7dc45d
      Luis R. Rodriguez authored
      This fixes a regression on disallowing bands introduced with the new
      802.11d support. The issue is that IEEE-802.11 allows APs to send
      a subset of what a country regulatory domain defines. This was clarified
      in this document:
      
      http://tinyurl.com/11d-clarification
      
      As such it is possible, and this is what is done in practice, that a
      single band 2.4 GHz AP will only send 2.4 GHz band regulatory information
      through the 802.11 country information element and then the current
      intersection with what CRDA provided yields a regulatory domain with
      no 5 GHz information -- even though that country may actually allow
      5 GHz operation. We correct this by only applying the intersection rules
      on a channel if the the intersection yields a regulatory rule on the
      same band the channel is on.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0c7dc45d
    • Luis R. Rodriguez's avatar
      cfg80211: make handle_band() and handle_channel() wiphy specific · a92a3ce7
      Luis R. Rodriguez authored
      This allows us to make more wiphy specific judgements when
      handling the channels later on.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a92a3ce7
    • Zhu Yi's avatar
      iwlwifi: remove CMD_WANT_SKB flag if send_cmd_sync failure · 73e1a65d
      Zhu Yi authored
      In function iwl_send_cmd_sync(), if the flag CMD_WANT_SKB is set but
      we are not provided with a valid SKB (cmd->meta.u.skb == NULL), we need
      to remove the CMD_WANT_SKB flag from the TX cmd queue. Otherwise in case
      the cmd comes in later, it will possibly set an invalid address. Thus
      it causes an invalid memory access.
      
      This fixed the bug http://bugzilla.kernel.org/show_bug.cgi?id=11326.
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      73e1a65d
    • Jouni Malinen's avatar
      ath9k: Fix an operator typo in REG_DOMAIN_2GHZ_MASK · 9d97f2e5
      Jouni Malinen authored
      Incorrect operator causes the REG_DOMAIN_2GHZ_MASK to be zero which
      surely was not the goal of this definition. Mask out the 11a flags
      correctly.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9d97f2e5
    • Jouni Malinen's avatar
      ath9k: Fix an operator typo in phy rate validation · b657eade
      Jouni Malinen authored
      This was not supposed to be a bitwise AND operation, but a check of
      two separate conditions. Anyway, the old code happened to result in
      the same behavior, so this is just changing the code to be easier to
      understand and also to keep sparse from warning about dubious
      operators.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b657eade
    • Andrey Yurovsky's avatar
      libertas: Fix alignment issues in libertas core · d71038c0
      Andrey Yurovsky authored
      Data structures that come over the wire from the WLAN firmware must be packed.
      This fixes alignment problems on the blackfin architecture and, reportedly, on
      the AVR32.
      
      This is a replacement for the previous version of this patch which had also
      explicitly used get_unaligned_ macros.  As Johannes Berg pointed out, these
      macros were unnecessary.
      Signed-off-by: default avatarAndrey Yurovsky <andrey@cozybit.com>
      Signed-off-by: default avatarColin McCabe <colin@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d71038c0
    • Randy Dunlap's avatar
      mac80211: more kernel-doc fixes · b6b50a21
      Randy Dunlap authored
      Fix (delete) more mac80211 kernel-doc:
      
      Warning(linux-2.6.28-git13//include/net/mac80211.h:375): Excess struct/union/enum/typedef member 'retry_count' description in 'ieee80211_tx_info'
      Warning(linux-2.6.28-git13//net/mac80211/sta_info.h:308): Excess struct/union/enum/typedef member 'last_txrate' description in 'sta_info'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b6b50a21
    • Christian Lamparter's avatar
      p54: fix oops caused by bad eeproms · ef15aa49
      Christian Lamparter authored
      This patch fixes a bug that could occur, if it the eeprom is incomplete or partly corrupted.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000008
      IP: p54_assign_address+0x108/0x15d [p54common]
      Oops: 0002 [#1] SMP
      Pid: 12988, comm: phy1 Tainted: P        W  2.6.28-rc6-wl #3
      RIP: 0010: p54_assign_address+0x108/0x15d [p54common]
       [...]
      Call Trace:
       p54_alloc_skb+0xa3/0xc0 [p54common]
       p54_scan+0x37/0x204 [p54common]
       [...]
      Signed-off-by: default avatarChristian Lamparter <chunkeey@web.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ef15aa49
  2. 15 Jan, 2009 29 commits