1. 25 Jul, 2012 1 commit
  2. 13 Jun, 2012 1 commit
    • Eliad Peller's avatar
      cfg80211: fix potential deadlock in regulatory · fe20b39e
      Eliad Peller authored
      
      
      reg_timeout_work() calls restore_regulatory_settings() which
      takes cfg80211_mutex.
      
      reg_set_request_processed() already holds cfg80211_mutex
      before calling cancel_delayed_work_sync(reg_timeout),
      so it might deadlock.
      
      Call the async cancel_delayed_work instead, in order
      to avoid the potential deadlock.
      
      This is the relevant lockdep warning:
      
      cfg80211: Calling CRDA for country: XX
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.4.0-rc5-wl+ #26 Not tainted
      -------------------------------------------------------
      kworker/0:2/1391 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
      
      but task is already holding lock:
       ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((reg_timeout).work){+.+...}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c005b600>] wait_on_work+0x4c/0x154
             [<c005c000>] __cancel_work_timer+0xd4/0x11c
             [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
             [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
             [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
             [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
             [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
             [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
             [<c03c7584>] genl_rcv+0x28/0x34
             [<c03c6720>] netlink_unicast+0x15c/0x228
             [<c03c6c7c>] netlink_sendmsg+0x218/0x298
             [<c03933c8>] sock_sendmsg+0xa4/0xc0
             [<c039406c>] __sys_sendmsg+0x1e4/0x268
             [<c0394228>] sys_sendmsg+0x4c/0x70
             [<c0013840>] ret_fast_syscall+0x0/0x3c
      
      -> #1 (reg_mutex){+.+.+.}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      -> #0 (cfg80211_mutex){+.+.+.}:
             [<c008ed58>] print_circular_bug+0x68/0x2cc
             [<c008fb28>] validate_chain+0x978/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
             [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      other info that might help us debug this:
      
      Chain exists of:
        cfg80211_mutex --> reg_mutex --> (reg_timeout).work
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((reg_timeout).work);
                                     lock(reg_mutex);
                                     lock((reg_timeout).work);
        lock(cfg80211_mutex);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/0:2/1391:
       #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
       #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      stack backtrace:
      [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
      [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
      [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
      [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
      [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
      [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
      [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
      [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
      [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
      [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
      [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
      [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
      cfg80211: Calling CRDA to update world regulatory domain
      cfg80211: World regulatory domain updated:
      cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
      cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe20b39e
  3. 09 Apr, 2012 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB · 80007efe
      Luis R. Rodriguez authored
      It has happened twice now where elaborate troubleshooting has
      undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
      has been set but yet net/wireless/db.txt was not updated.
      
      Despite the documentation on this it seems system integrators could
      use some more help with this, so throw out a kernel warning at boot time
      when their database is empty.
      
      This does mean that the error-prone system integrator won't likely
      realize the issue until they boot the machine but -- it does not seem
      to make sense to enable a build bug breaking random build testing.
      
      [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB
      
      
      
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Youngsin Lee <youngsin@qualcomm.com>
      Cc: Raja Mani <rmani@qca.qualcomm.com>
      Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
      Cc: yahuan@qca.qualcomm.com
      Cc: jjan@qca.qualcomm.com
      Cc: vthiagar@qca.qualcomm.com
      Cc: henrykim@qualcomm.com
      Cc: jouni@qca.qualcomm.com
      Cc: athiruve@qca.qualcomm.com
      Cc: cjkim@qualcomm.com
      Cc: philipk@qca.qualcomm.com
      Cc: sunnykim@qualcomm.com
      Cc: sskwak@qualcomm.com
      Cc: kkim@qualcomm.com
      Cc: mattbyun@qualcomm.com
      Cc: ryanlee@qualcomm.com
      Cc: simbap@qualcomm.com
      Cc: krislee@qualcomm.com
      Cc: conner@qualcomm.com
      Cc: hojinkim@qualcomm.com
      Cc: honglee@qualcomm.com
      Cc: johnwkim@qualcomm.com
      Cc: jinyong@qca.qualcomm.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      80007efe
  4. 24 Jan, 2012 1 commit
    • Hong Wu's avatar
      wireless: Save original maximum regulatory transmission power for the... · eccc068e
      Hong Wu authored
      
      wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit power
      
      The local maximum transmit power is the maximum power a wireless device
      allowed to transmit. If Power Constraint is presented, the local maximum
      power equals to the maximum allowed power defined in regulatory domain
      minus power constraint.
      
      The maximum transmit power is maximum power a wireless device capable of
      transmitting, and should be used in Power Capability element (7.3.2.16
      IEEE802.11 2007).
      
      The transmit power from a wireless device should not greater than the
      local maximum transmit power.
      
      The maximum transmit power was not calculated correctly in the current
      Linux wireless/mac80211 when Power Constraint is presented.
      Signed-off-by: default avatarHong Wu <hong.wu@dspg.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eccc068e
  5. 04 Jan, 2012 4 commits
  6. 16 Dec, 2011 2 commits
    • Rajkumar Manoharan's avatar
      cfg80211: Restore orig channel values upon disconnect · 5ce543d1
      Rajkumar Manoharan authored
      
      
      When we restore regulatory settings the world regulatory domain
      is properly reset on cfg80211 (or user prefered regulatory domain)
      but we were never setting back channel values for drivers that use
      WIPHY_FLAG_CUSTOM_REGULATORY. Set these values up again by using
      the orig_ channel parameters.
      
      This fixes restoring custom regulatory settings upon disconnect
      events.
      
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5ce543d1
    • Luis R. Rodriguez's avatar
      cfg80211: allow following country IE power for custom regdom cards · 061acaae
      Luis R. Rodriguez authored
      
      
      By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the
      wiphy to adjust itself to the country IE power information if the
      card had no regulatory data but we had no way to tell cfg80211 that if
      the card also had its own custom regulatory domain (these are typically
      custom world regulatory domains) that we want to follow the country IE's
      noted values for power for each channel. We add support for this and
      document it.
      
      This is not a critical fix but a performance optimization for cards
      with custom regulatory domains that associate to an AP with sends
      out country IEs with a higher EIRP than the one on the custom
      regulatory domain. In practice the only driver affected right now
      are the Atheros drivers as they are the only drivers using both
      WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY --
      used on cards that have an Atheros world regulatory domain. Cards
      that have been programmed to follow a country specifically will not
      follow the country IE power. So although not a stable fix distributions
      should consider cherry picking this.
      
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Reported-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      061acaae
  7. 13 Dec, 2011 1 commit
  8. 30 Nov, 2011 2 commits
  9. 21 Nov, 2011 3 commits
  10. 09 Nov, 2011 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: fix bug on regulatory core exit on access to last_request · 58ebacc6
      Luis R. Rodriguez authored
      Commit 4d9d88d1 by Scott James Remnant <keybuk@google.com> added
      the .uevent() callback for the regulatory device used during
      the platform device registration. The change was done to account
      for queuing up udev change requests through udevadm triggers.
      The change also meant that upon regulatory core exit we will now
      send a uevent() but the uevent() callback, reg_device_uevent(),
      also accessed last_request. Right before commiting device suicide
      we free'd last_request but never set it to NULL so
      platform_device_unregister() would lead to bogus kernel paging
      request. Fix this and also simply supress uevents right before
      we commit suicide as they are pointless.
      
      This fix is required for kernels >= v2.6.39
      
      $ git describe --contains 4d9d88d1
      
      
      v2.6.39-rc1~468^2~25^2^2~21
      
      The impact of not having this present is that a bogus paging
      access may occur (only read) upon cfg80211 unload time. You
      may also get this BUG complaint below. Although Johannes
      could not reproduce the issue this fix is theoretically correct.
      
      mac80211_hwsim: unregister radios
      mac80211_hwsim: closing netlink
      BUG: unable to handle kernel paging request at ffff88001a06b5ab
      IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
      PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
      Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0
      Modules linked in: cfg80211(-) [last unloaded: mac80211]
      
      Pid: 2279, comm: rmmod Tainted: G        W   3.1.0-wl+ #663 Bochs Bochs
      RIP: 0010:[<ffffffffa030df9a>]  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
      RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
      RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
      RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
      RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
      R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
      R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
      FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
      Stack:
       ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
       000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
       ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
      Call Trace:
       [<ffffffff812ff7e5>] dev_uevent+0xc5/0x170
       [<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490
       [<ffffffff81040189>] ? sub_preempt_count+0x29/0x60
       [<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
       [<ffffffff81305307>] ? devres_release_all+0x27/0x60
       [<ffffffff8124206b>] kobject_uevent+0xb/0x10
       [<ffffffff812fee27>] device_del+0x157/0x1b0
       [<ffffffff8130377d>] platform_device_del+0x1d/0x90
       [<ffffffff81303b76>] platform_device_unregister+0x16/0x30
       [<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211]
       [<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211]
       [<ffffffff8109a84c>] sys_delete_module+0x16c/0x220
       [<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120
       [<ffffffff814cba02>] system_call_fastpath+0x16/0x1b
      Code: <all your base are belong to me>
      RIP  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
       RSP <ffff88001c5f9d58>
      CR2: ffff88001a06b5ab
      ---[ end trace 147c5099a411e8c0 ]---
      Reported-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: Scott James Remnant <keybuk@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      58ebacc6
  11. 31 Oct, 2011 2 commits
  12. 16 Sep, 2011 1 commit
  13. 14 Sep, 2011 2 commits
  14. 13 Sep, 2011 1 commit
  15. 09 Aug, 2011 1 commit
  16. 26 Jul, 2011 2 commits
    • Mihai Moldovan's avatar
      wireless: fix a typo in ignore_reg_update · 5bc91db8
      Mihai Moldovan authored
      
      
      Just a typo fix changing regulaotry to regulatory.
      Signed-off-by: default avatarMihai Moldovan <ionic@ionic.de>
      CC: John W. Linville <linville@tuxdriver.com>
      CC: Mohammed Shafi <shafi.wireless@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5bc91db8
    • Sven Neumann's avatar
      cfg80211: really ignore the regulatory request · a203c2aa
      Sven Neumann authored
      
      
      At the beginning of wiphy_update_regulatory() a check is performed
      whether the request is to be ignored. Then the request is sent to
      the driver nevertheless. This happens even if last_request points
      to NULL, leading to a crash in the driver:
      
       [<bf01d864>] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4)
       [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4) from [<c03b4008>] (wiphy_register+0x354/0x420)
       [<c03b4008>] (wiphy_register+0x354/0x420) from [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas])
       [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas]) from [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas])
       [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas]) from [<bf02cbd8>] (if_sdio_probe+0x898/0x9c0 [libertas_sdio])
      
      Fix this by returning early. Also remove the out: label as it is
      not any longer needed.
      Signed-off-by: default avatarSven Neumann <s.neumann@raumfeld.com>
      Cc: linux-wireless@vger.kernel.org
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Daniel Mack <daniel@zonque.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a203c2aa
  17. 10 May, 2011 1 commit
  18. 26 Apr, 2011 1 commit
  19. 07 Apr, 2011 2 commits
  20. 31 Mar, 2011 1 commit
  21. 09 Mar, 2011 1 commit
  22. 21 Jan, 2011 1 commit
    • Bruno Randolf's avatar
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf authored
      
      
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  23. 04 Jan, 2011 1 commit
  24. 16 Dec, 2010 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: fix null pointer dereference with a custom regulatory request · 2784fe91
      Luis R. Rodriguez authored
      
      
      Once we moved the core regulatory request to the queue and let
      the scheduler process it last_request will have been left NULL
      until the schedular decides to process the first request. When
      this happens and we are loading a driver with a custom regulatory
      request like all Atheros drivers we end up with a NULL pointer
      dereference. We fix this by checking if the request was a
      custom one.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      IP: [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      PGD 71f91067 PUD 712b2067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/firmware/2-1/loading
      CPU 0
      Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath <etc>
      Pid: 3094, comm: insmod Tainted: G        W   2.6.37-rc5-wl #16 INVALID/28427ZQ
      RIP: 0010:[<ffffffffa016de87>]  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      RSP: 0018:ffff88007045db78  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffffffffa047d9a0 RCX: ffff88007045dbd0
      RDX: 0000000000004e20 RSI: 000000000024cde0 RDI: ffff8800700483e0
      RBP: ffff88007045db98 R08: ffffffffa02f5b40 R09: 0000000000000001
      R10: 000000000000000e R11: 0000000000000001 R12: 0000000000000000
      R13: ffff88007004e3b0 R14: 0000000000000000 R15: ffff880070048340
      FS:  00007f635a707700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000004 CR3: 00000000708a9000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process insmod (pid: 3094, threadinfo ffff88007045c000, task ffff8800713e3ec0)
      Stack:
       ffffffffa047d9a0 0000000000000000 ffff88007004e3b0 0000000000000000
       ffff88007045dc08 ffffffffa016e147 000000007045dc08 0000000000000002
       ffff8800700483e0 ffffffffa02f5b40 ffff88007045dbd8 0000000000000000
      Call Trace:
       [<ffffffffa016e147>] wiphy_apply_custom_regulatory+0x137/0x1d0 [cfg80211]
       [<ffffffffa047a690>] ? ath9k_reg_notifier+0x0/0x50 [ath9k_htc]
       [<ffffffffa02f47f7>] ath_regd_init+0x347/0x430 [ath]
       [<ffffffffa047b1f5>] ath9k_htc_probe_device+0x6c5/0x960 [ath9k_htc]
       [<ffffffffa0472a2c>] ath9k_htc_hw_init+0xc/0x30 [ath9k_htc]
       [<ffffffffa04747e6>] ath9k_hif_usb_probe+0x216/0x3b0 [ath9k_htc]
       [<ffffffffa03bb6bc>] usb_probe_interface+0x10c/0x210 [usbcore]
       [<ffffffff812aec26>] driver_probe_device+0x96/0x1c0
       [<ffffffff812aedf3>] __driver_attach+0xa3/0xb0
       [<ffffffff812aed50>] ? __driver_attach+0x0/0xb0
       [<ffffffff812adaae>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ae8c9>] driver_attach+0x19/0x20
       [<ffffffff812ae438>] bus_add_driver+0x168/0x320
       [<ffffffff812af071>] driver_register+0x71/0x140
       [<ffffffff811fc4a8>] ? __raw_spin_lock_init+0x38/0x70
       [<ffffffffa03ba39c>] usb_register_driver+0xdc/0x190 [usbcore]
       [<ffffffffa03a2000>] ? ath9k_htc_init+0x0/0x4f [ath9k_htc]
       [<ffffffffa047499e>] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc]
       [<ffffffffa03a202b>] ath9k_htc_init+0x2b/0x4f [ath9k_htc]
       [<ffffffff8100212f>] do_one_initcall+0x3f/0x180
       [<ffffffff8109ef5b>] sys_init_module+0xbb/0x200
       [<ffffffff8100bf52>] system_call_fastpath+0x16/0x1b
      Code: <etc, who cares>
      RIP  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
       RSP <ffff88007045db78>
      CR2: 0000000000000004
      ---[ end trace 79e4193601c8b713 ]---
      Reported-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2784fe91
  25. 24 Nov, 2010 1 commit
  26. 22 Nov, 2010 4 commits