1. 29 11月, 2011 3 次提交
    • S
      rtlwifi: fix lps_lock deadlock · e55b32c1
      Stanislaw Gruszka 提交于
      rtl_lps_leave can be called from interrupt context, so we have to
      disable interrupts when taking lps_lock.
      
      Below is full lockdep info about deadlock:
      
      [   93.815269] =================================
      [   93.815390] [ INFO: inconsistent lock state ]
      [   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815556] ---------------------------------
      [   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.815947] {SOFTIRQ-ON-W} state was registered at:
      [   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
      [   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
      [   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
      [   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
      [   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
      [   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
      [   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
      [   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
      [   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
      [   93.815947] irq event stamp: 547822
      [   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
      [   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
      [   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
      [   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.815947]
      [   93.815947] other info that might help us debug this:
      [   93.815947]  Possible unsafe locking scenario:
      [   93.815947]
      [   93.815947]        CPU0
      [   93.815947]        ----
      [   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]   <Interrupt>
      [   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]
      [   93.815947]  *** DEADLOCK ***
      [   93.815947]
      [   93.815947] no locks held by swapper/0.
      [   93.815947]
      [   93.815947] stack backtrace:
      [   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815947] Call Trace:
      [   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
      [   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
      [   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
      [   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
      [   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
      [   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
      [   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
      [   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
      [   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
      [   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
      [   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
      [   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
      [   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
      [   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
      [   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
      [   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
      [   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
      [   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
      [   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
      [   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
      [   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
      [   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
      [   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
      [   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
      [   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
      [   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111
      
      Resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=755154
      
      Reported-by: vjain02@students.poly.edu
      Reported-and-tested-by: NOliver Paukstadt <pstadt@sourcentral.org>
      Cc: stable@vger.kernel.org
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e55b32c1
    • J
      mac80211: don't stop a single aggregation session twice · 24f50a9d
      Johannes Berg 提交于
      Nikolay noticed (by code review) that mac80211 can
      attempt to stop an aggregation session while it is
      already being stopped. So to fix it, check whether
      stop is already being done and bail out if so.
      
      Also move setting the STOPPING state into the lock
      so things are properly atomic.
      
      Cc: stable@vger.kernel.org
      Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      24f50a9d
    • E
      nl80211: fix MAC address validation · e007b857
      Eliad Peller 提交于
      MAC addresses have a fixed length. The current
      policy allows passing < ETH_ALEN bytes, which
      might result in reading beyond the buffer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e007b857
  2. 23 11月, 2011 2 次提交
  3. 22 11月, 2011 4 次提交
  4. 18 11月, 2011 5 次提交
  5. 15 11月, 2011 3 次提交
  6. 12 11月, 2011 2 次提交
    • A
      mwifiex: fix association issue with AP configured in hidden SSID mode · fada1058
      Amitkumar Karwar 提交于
      Firmware expects 'max_ssid_length' field in
      'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for
      performing SSID specific scan. Currently driver updates it with
      an actual SSID length. Hence UUT is not able to find the AP
      configured in hidden SSID mode in scan results and association
      fails.
      
      max_ssid_length is filled with '0' to fix the issue.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fada1058
    • E
      iwlwifi: avoid a panic when unloading the module with RF Kill · 43e58856
      Emmanuel Grumbach 提交于
      When HW RF kill switch is set to kill the radio, our NIC issues an
      interrupt after we stop the APM module. When we unload the module,
      the driver disables and cleans the interrupts before stopping the
      APM. So we have a real interrupt (inta not zero) pending.
      When this interrupts pops up the tasklet has already been killed
      and we crash.
      
      Here is a logical description of the flow:
      
      disable and clean interrupts
      synchronize interrupts
      kill the tasklet
      
      stop the APM <<== creates an RF kill interrupt
      
      free_irq <<== somehow our ISR is called here and we crash
      
      Here is the panic message:
      
      [  201.313636] BUG: unable to handle kernel paging request at ffff8800911b7150
      [  201.314541] IP: [<ffffffff8106d652>] tasklet_action+0x62/0x130
      [  201.315149] PGD 1c06063 PUD db37f067 PMD db408067 PTE 80000000911b7160
      [  201.316456] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [  201.317324] CPU 1
      [  201.317495] Modules linked in: arc4 iwlwifi(-) mac80211 cfg80211 netconsole configfs binfmt_misc i915 drm_kms_helper drm uvcvideo i2c_algo_bit videodev dell_laptop dcdbas intel_agp dell_wmi intel_ips psmouse intel_gtt v4l2_compat_ioctl32 asix usbnet mii serio_raw video sparse_keymap firewire_ohci sdhci_pci sdhci firewire_core e1000e crc_itu_t [last unloaded: configfs]
      [  201.323839]
      [  201.324015] Pid: 2061, comm: modprobe Not tainted 3.1.0-rc9-wl #4 Dell Inc. Latitude E6410/0667CC
      [  201.324736] RIP: 0010:[<ffffffff8106d652>]  [<ffffffff8106d652>] tasklet_action+0x62/0x130
      [  201.325128] RSP: 0018:ffff88011bc43ea0  EFLAGS: 00010286
      [  201.325338] RAX: ffff88008ae70000 RBX: ffff8800911b7150 RCX: ffff88008ae70028
      [  201.325555] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88008ae70000
      [  201.325775] RBP: ffff88011bc43ec0 R08: 0000000000000000 R09: 0000000000000000
      [  201.325994] R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000001
      [  201.326212] R13: 0000000000000006 R14: 0000000000000100 R15: ffff88008e259fd8
      [  201.326431] FS:  00007f4b90ea9700(0000) GS:ffff88011bc40000(0000) knlGS:0000000000000000
      [  201.326657] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  201.326864] CR2: ffff8800911b7150 CR3: 000000008fd6d000 CR4: 00000000000006e0
      [  201.327083] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  201.327302] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  201.327521] Process modprobe (pid: 2061, threadinfo ffff88008e258000, task ffff88008ae70000)
      [  201.327747] Stack:
      [  201.330494]  0000000000000046 0000000000000030 0000000000000001 0000000000000006
      [  201.333870]  ffff88011bc43f30 ffffffff8106cd8a ffffffff811e1016 ffff88011bc43f08
      [  201.337186]  0000000100000046 ffff88008e259fd8 0000000a10be2160 0000000000000006
      [  201.340458] Call Trace:
      [  201.342994]  <IRQ>
      [  201.345656]  [<ffffffff8106cd8a>] __do_softirq+0xca/0x250
      [  201.348185]  [<ffffffff811e1016>] ? pde_put+0x76/0x90
      [  201.350730]  [<ffffffff8131aeae>] ? do_raw_spin_unlock+0x5e/0xb0
      [  201.353261]  [<ffffffff811e1016>] ? pde_put+0x76/0x90
      [  201.355776]  [<ffffffff8163ccfc>] call_softirq+0x1c/0x30
      [  201.358287]  [<ffffffff8101531d>] do_softirq+0x9d/0xd0
      [  201.360823]  [<ffffffff8106cb05>] irq_exit+0xd5/0xf0
      [  201.363330]  [<ffffffff8163d5d6>] do_IRQ+0x66/0xe0
      [  201.365819]  [<ffffffff81632673>] common_interrupt+0x73/0x73
      [  201.368257]  <EOI>
      
      Cc: <stable@kernel.org> 3.1+
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      43e58856
  7. 10 11月, 2011 5 次提交
    • J
      mac80211: fix race between connection monitor & suspend · 0ecfe806
      Johannes Berg 提交于
      When the connection monitor timer fires right before
      suspend, the following will happen:
       timer fires -> monitor_work gets queued
       suspend calls ieee80211_sta_quiesce
       ieee80211_sta_quiesce:
        - deletes timer
        - cancels monitor_work synchronously, running it
        [note wrong order of these steps]
       monitor_work runs, re-arming the timer
       later, timer fires while system should be quiesced
      
      This causes a warning:
      
      WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x35/0x40 [mac80211]()
      
      but is otherwise harmless. I'm not completely sure
      this is the scenario Thomas stumbled across, but it
      is the only way I can right now see the warning in
      a scenario like the one he reported.
      Reported-by: NThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0ecfe806
    • S
      wireless: libertas: fix unaligned le64 accesses · d929bbc6
      Steven Miao 提交于
      use get_unaligned_le64() to get timestamp
      Signed-off-by: NSteven Miao <realmz6@gmail.com>
      Acked-by: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d929bbc6
    • L
      cfg80211: fix bug on regulatory core exit on access to last_request · 58ebacc6
      Luis R. Rodriguez 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Scott James Remnant <keybuk@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      58ebacc6
    • J
      mac80211: fix bug in ieee80211_build_probe_req · 5b2bbf75
      Johannes Berg 提交于
      ieee80211_probereq_get() can return NULL in
      which case we should clean up & return NULL
      in ieee80211_build_probe_req() as well.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5b2bbf75
    • J
      mac80211: fix NULL dereference in radiotap code · f8d1ccf1
      Johannes Berg 提交于
      When receiving failed PLCP frames is enabled, there
      won't be a rate pointer when we add the radiotap
      header and thus the kernel will crash. Fix this by
      not assuming the rate pointer is always valid. It's
      still always valid for frames that have good PLCP
      though, and that is checked & enforced.
      
      This was broken by my
      commit fc885189
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Fri Jul 30 13:23:12 2010 +0200
      
          mac80211: don't check rates on PLCP error frames
      
      where I removed the check in this case but didn't
      take into account that the rate info would be used.
      Reported-by: NXiaokang Qin <xiaokang.qin@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f8d1ccf1
  8. 09 11月, 2011 4 次提交
    • E
      wl12xx: fix wl12xx_scan_sched_scan_ssid_list() check that all given ssids are in filters · cc438fcc
      Eyal Shapira 提交于
      A minor fix for the check that verifies that all given SSIDs (in req) exist
      in the filters (the match sets)
      Signed-off-by: NEyal Shapira <eyal@wizery.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cc438fcc
    • H
      ath: Fix NULL ptr dereference in ath_reg_apply_world_flags · a59be081
      Helmut Schaa 提交于
      This happens with devices using a regulatory domain 0x68 that are only
      5Ghz capable because ath_reg_apply_active_scan_flags assumes that we
      always have a 2,4Ghz band.
      
      CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 82cd838c, ra == 82cd8384
      Oops[#1]:
      Cpu 0
      $ 0 : 00000000 00000061 00000003 00000024
      $ 4 : 00000003 000016c1 82f900ac 00000024
      $ 8 : 00000000 82cda304 0058bad8 00000005
      $12 : 005908f8 001e8481 00000003 1dcd6500
      $16 : 00000002 00000000 82c700c0 82c700c0
      $20 : 82d415e4 82c70d64 82c70200 82c715bc
      $24 : 00000000 11e1a300
      $28 : 82ce2000 82ce3c70 82c715a8 82cd8384
      Hi : 00000000
      Lo : 0000001e
      epc : 82cd838c ath_reg_apply_world_flags+0x78/0x17c [ath]
      Not tainted
      ra : 82cd8384 ath_reg_apply_world_flags+0x70/0x17c [ath]
      Status: 1000d403 KERNEL EXL IE
      Cause : 80800008
      BadVA : 00000000
      PrId : 00019374 (MIPS 24Kc)
      Modules linked in: ath9k(+) ath9k_common ath9k_hw ath mac80211 cfg80211
      	compat_firmware_class compat arc4 aes_generic deflate ecb cbc
      	leds_gpio button_hotplug gpio_buttons input_polldev ie
      Process insmod (pid: 464, threadinfo=82ce2000, task=838b31d8, tls=00000000)
      Stack : 00000000 00000002 82f900ac 82c700c0 82d415e4 82c70d64 00000000 00000068
      82f900ac 82cd88f4 82c700c0 82cda304 00000001 000020f0 82f90000 82c70d40
      00000002 82f90000 82f900ac 82d4207c 82d518a0 00000002 7fee6118 8017c0d8
      00000008 8397ba00 82c70d40 00000000 82c70200 83813000 83813058 b0010000
      82d518a0 00000002 7fee6118 82d4b8c8 83445cc0 80120dc0 83804000 800eeda0
      ...
      Call Trace:
      [<82cd838c>] ath_reg_apply_world_flags+0x78/0x17c [ath]
      [<82cd88f4>] ath_regd_init+0x464/0x488 [ath]
      [<82d4207c>] ath9k_init_device+0x6a4/0x6b4 [ath9k]
      [<82d4b8c8>] ath_pci_probe+0x27c/0x358 [ath9k]
      [<80181de0>] pci_device_probe+0x64/0xa4
      [<8019e874>] driver_probe_device+0xb8/0x190
      [<8019e9b8>] __driver_attach+0x6c/0xa4
      [<8019dfc0>] bus_for_each_dev+0x60/0xb0
      [<8019d744>] bus_add_driver+0xc4/0x25c
      [<8019ed6c>] driver_register+0xe0/0x198
      [<8018206c>] __pci_register_driver+0x50/0xe0
      [<82dd0010>] ath9k_init+0x10/0x54 [ath9k]
      [<8006b4a0>] do_one_initcall+0x68/0x1ec
      [<800a901c>] sys_init_module+0xec/0x23c
      [<80062544>] stack_done+0x20/0x3c
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a59be081
    • J
      cfg80211: fix missing kernel-doc · c26887d2
      Johannes Berg 提交于
      Two new struct members were not documented, fix that.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c26887d2
    • J
  9. 08 11月, 2011 12 次提交