1. 20 Jul, 2010 1 commit
  2. 16 Jul, 2010 1 commit
    • Stephen Boyd's avatar
      rt2x00: Fix lockdep warning in rt2x00lib_probe_dev() · 9acd56d3
      Stephen Boyd authored
      The rt2x00dev->intf_work workqueue is never initialized when a driver is
      probed for a non-existent device (in this case rt2500usb). On such a
      path we call rt2x00lib_remove_dev() to free any resources initialized
      during the probe before we use INIT_WORK to initialize the workqueue.
      This causes lockdep to get confused since the lock used in the workqueue
      hasn't been initialized yet but is now being acquired during
      cancel_work_sync() called by rt2x00lib_remove_dev().
      
      Fix this by initializing the workqueue first before we attempt to probe
      the device. This should make lockdep happy and avoid breaking any
      assumptions about how the library cleans up after a probe fails.
      
      phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
      Call Trace:
       [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
       [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
       [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
       [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff81492aef>] ?  _raw_spin_unlock_irqrestore+0x33/0x41
       [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
       [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
       [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
       [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
       [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
       [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
       [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
       [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
       [<ffffffff812ea167>] __driver_attach+0x4a/0x66
       [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
       [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
       [<ffffffff812e9efd>] driver_attach+0x19/0x1b
       [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
       [<ffffffff812ea41b>] driver_register+0x98/0x109
       [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
       [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
       [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
       [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
       [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
       [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarStephen Boyd <bebarino@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9acd56d3
  3. 14 Jul, 2010 1 commit
    • John W. Linville's avatar
      hostap_pci: set dev->base_addr during probe · 0f4da2d7
      John W. Linville authored
      "hostap: Protect against initialization interrupt" (which reinstated
      "wireless: hostap, fix oops due to early probing interrupt")
      reintroduced Bug 16111.  This is because hostap_pci wasn't setting
      dev->base_addr, which is now checked in prism2_interrupt.  As a result,
      initialization was failing for PCI-based hostap devices.  This corrects
      that oversight.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0f4da2d7
  4. 07 Jul, 2010 1 commit
  5. 02 Jul, 2010 1 commit
  6. 25 Jun, 2010 2 commits
    • Wey-Yi Guy's avatar
      iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag · 062bee44
      Wey-Yi Guy authored
      When building tx command, always set TX_CMD_FLAG_PROT_REQUIRE_MSK
      for 5000 series and up.
      
      Without setting this bit the firmware will not examine the RTS/CTS setting
      and thus not send traffic with the appropriate protection. RTS/CTS is is
      required for HT traffic in a noisy environment where, without this setting,
      connections will stall on some hardware as documented in the patch that
      initially attempted to address this:
      
          commit 1152dcc2
          Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
          Date:   Fri Jan 15 13:42:58 2010 -0800
      
          iwlwifi: Fix throughput stall issue in HT mode for 5000
      
          Similar to 6000 and 1000 series, RTS/CTS is the recommended
          protection mechanism for 5000 series in HT mode based on the HW design.
          Using RTS/CTS will better protect the inner exchange from interference,
          especially in highly-congested environment, it also prevent uCode encounter
          TX FIFO underrun and other HT mode related performance issues.
      
      For 3945 and 4965, different flags are used for RTS/CTS or CTS-to-Self
      protection.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      062bee44
    • Johannes Berg's avatar
      iwlwifi: fix multicast · d1e89f37
      Johannes Berg authored
      commit 3474ad63
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Apr 29 04:43:05 2010 -0700
      
          iwlwifi: apply filter flags directly
      
      broke multicast. The reason, it turns out, is that
      the code previously checked if ALLMULTI _changed_,
      which the new code no longer did, and normally it
      _never_ changes. Had somebody changed it manually,
      the code prior to my patch there would have been
      broken already.
      
      The reason is that we always, unconditionally, ask
      the device to pass up all multicast frames, but the
      new code made it depend on ALLMULTI which broke it
      since now we'd pass up multicast frames depending
      on the default filter in the device, which isn't
      necessarily what we want (since we don't program it
      right now).
      
      Fix this by simply not checking allmulti as we have
      allmulti behaviour enabled already anyway.
      Reported-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d1e89f37
  7. 23 Jun, 2010 1 commit
    • Vasanthakumar Thiagarajan's avatar
      ath9k: Fix bug in starting ani · 6c3118e2
      Vasanthakumar Thiagarajan authored
      There are few places where ANI is started without checking
      if it is right to start. This might lead to a case where ani
      timer would be left undeleted and cause improper memory acccess
      during module unload. This bug is clearly exposed with
      paprd support where the driver detects tx hang and does a
      chip reset. During this reset ani is (re)started without checking
      if it needs to be started. This would leave a timer scheduled
      even after all the resources are freed and cause a panic.
      
      This patch introduces a bit in sc_flags to indicate if ani
      needs to be started in sw_scan_start() and ath_reset().
      This would fix the following panic. This issue is easily seen
      with ar9003 + paprd.
      
       BUG: unable to handle kernel paging request at 0000000000003f38
      [<ffffffff81075391>] ? __queue_work+0x41/0x50
      [<ffffffff8106afaa>] run_timer_softirq+0x17a/0x370
      [<ffffffff81088be8>] ? tick_dev_program_event+0x48/0x110
      [<ffffffff81061f69>] __do_softirq+0xb9/0x1f0
      [<ffffffff810ba060>] ? handle_IRQ_event+0x50/0x160
      [<ffffffff8100af5c>] call_softirq+0x1c/0x30
      [<ffffffff8100c9f5>] do_softirq+0x65/0xa0
      [<ffffffff81061e25>] irq_exit+0x85/0x90
      [<ffffffff8155e095>] do_IRQ+0x75/0xf0
      [<ffffffff815570d3>] ret_from_intr+0x0/0x11
      <EOI>
      [<ffffffff812fd67b>] ? acpi_idle_enter_simple+0xe4/0x119
      [<ffffffff812fd674>] ? acpi_idle_enter_simple+0xdd/0x119
      [<ffffffff81441c87>] cpuidle_idle_call+0xa7/0x140
      [<ffffffff81008da3>] cpu_idle+0xb3/0x110
      [<ffffffff81550722>] start_secondary+0x1ee/0x1f5
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6c3118e2
  8. 18 Jun, 2010 1 commit
    • Bob Copeland's avatar
      ath5k: initialize ah->ah_current_channel · b6855772
      Bob Copeland authored
      ath5k assumes ah_current_channel is always a valid pointer in
      several places, but a newly created interface may not have a
      channel.  To avoid null pointer dereferences, set it up to point
      to the first available channel until later reconfigured.
      
      This fixes the following oops:
      $ rmmod ath5k
      $ insmod ath5k
      $ iw phy0 set distance 11000
      
      BUG: unable to handle kernel NULL pointer dereference at 00000006
      IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      *pde = 00000000
      Oops: 0000 [#1]
      last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
      Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
      scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
      8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc
      
      Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
      EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
      EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
      ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
        DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
      Stack:
        d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
      <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
      <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
      Call Trace:
        [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
        [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
        [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
        [<c10f5db9>] ? nla_parse+0x59/0xc0
        [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
        [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
        [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
        [<c11c9649>] ? genl_rcv+0x19/0x30
        [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
        [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
        [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
        [<c1032780>] ? autoremove_wake_function+0x0/0x50
        [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
        [<c1074933>] ? do_lookup+0x53/0x1b0
        [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
        [<c11acab0>] ? verify_iovec+0x50/0x90
        [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
        [<c1048e50>] ? find_get_page+0x10/0x50
        [<c104a96f>] ? filemap_fault+0x5f/0x370
        [<c1059159>] ? __do_fault+0x319/0x370
        [<c11a55b4>] ? sys_socketcall+0x244/0x290
        [<c101962c>] ? do_page_fault+0x1ec/0x270
        [<c1019440>] ? do_page_fault+0x0/0x270
        [<c1002ae5>] ? syscall_call+0x7/0xb
      Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
      0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7
      43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
      EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
      0068:cfa09bf4
      CR2: 0000000000000006
      ---[ end trace 54f73d6b10ceb87b ]---
      
      Cc: stable@kernel.org
      Reported-by: default avatarSteve Brown <sbrown@cortland.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b6855772
  9. 16 Jun, 2010 1 commit
  10. 15 Jun, 2010 2 commits
    • Tim Gardner's avatar
      hostap: Protect against initialization interrupt · d6a574ff
      Tim Gardner authored
      Use an irq spinlock to hold off the IRQ handler until
      enough early card init is complete such that the handler
      can run without faulting.
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d6a574ff
    • John W. Linville's avatar
      iwlwifi: cancel scan watchdog in iwl_bg_abort_scan · a69b03e9
      John W. Linville authored
      Avoids this:
      
      WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1
      [mac80211]()
      Hardware name: Latitude E5400
      Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat
      nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand
      acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6
      ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb
      snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec
      snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci
      iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer
      iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore
      microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t
      yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video
      output [last unloaded: scsi_wait_scan]
      Pid: 979, comm: iwlagn Tainted: G        W  2.6.33.3-85.fc13.x86_64 #1
      Call Trace:
      [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f
      [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11
      [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211]
      [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore]
      [<ffffffff81060d3d>] worker_thread+0x1a4/0x232
      [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore]
      [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34
      [<ffffffff81060b99>] ? worker_thread+0x0/0x232
      [<ffffffff810643c7>] kthread+0x7a/0x82
      [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
      [<ffffffff8106434d>] ? kthread+0x0/0x82
      [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
      
      Reported here:
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=590436Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Reported-by: default avatarMihai Harpau <mishu@piatafinanciara.ro>
      Cc: stable@kernel.org
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      a69b03e9
  11. 14 Jun, 2010 5 commits
  12. 08 Jun, 2010 2 commits
  13. 07 Jun, 2010 5 commits
  14. 06 Jun, 2010 4 commits
    • Emmanuel Grumbach's avatar
      iwlwifi: move sysfs_create_group to post request firmware · 7d47618a
      Emmanuel Grumbach authored
      Move the sysfs_create_group to iwl_ucode_callback after we
      have safely got the firmware.
      
      The motivation to do this comes from a warning from lockdep which detected
      that we request priv->mutex while holding s_active during a sysfs request
      (show_statistics in the example copy pasted). The reverse order exists upon
      request_firmware: request_firmware which is a sysfs operation
      that requires s_active is run under priv->mutex.
      
      This ensures that we don't get sysfs request before we finish to request
      the firmware, avoiding this deadlock.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      -------------------------------------------------------
      cat/2595 is trying to acquire lock:
       (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
      
      but task is already holding lock:
       (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (s_active){++++.+}:
             [<c0489b74>] __lock_acquire+0xc44/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c0581499>] sysfs_addrm_finish+0xe9/0x180
             [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
             [<c05829d4>] sysfs_remove_group+0x44/0xd0
             [<c0714b75>] dpm_sysfs_remove+0x15/0x20
             [<c070dac8>] device_del+0x38/0x170
             [<c070dc1e>] device_unregister+0x1e/0x60
             [<c071838d>] _request_firmware+0x29d/0x550
             [<c07186c7>] request_firmware+0x17/0x20
             [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
             [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
             [<c0808cd2>] dev_open+0x92/0xf0
             [<c0808b2b>] dev_change_flags+0x7b/0x190
             [<c08148e8>] do_setlink+0x178/0x3b0
             [<c0815169>] rtnl_setlink+0xf9/0x130
             [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
             [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
             [<c081436c>] rtnetlink_rcv+0x1c/0x30
             [<c08279c3>] netlink_unicast+0x263/0x290
             [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
             [<c07f85fd>] sock_sendmsg+0xcd/0x100
             [<c07f964d>] sys_sendmsg+0x15d/0x290
             [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      -> #0 (&priv->mutex){+.+.+.}:
             [<c0489f84>] __lock_acquire+0x1054/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c08bb358>] __mutex_lock_common+0x58/0x470
             [<c08bb84a>] mutex_lock_nested+0x3a/0x50
             [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
             [<c070d219>] dev_attr_show+0x29/0x50
             [<c057fecd>] sysfs_read_file+0xdd/0x190
             [<c052880f>] vfs_read+0x9f/0x190
             [<c0528d22>] sys_read+0x42/0x70
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      other info that might help us debug this:
      
      3 locks held by cat/2595:
       #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
       #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
       #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      stack backtrace:
      Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
      Call Trace:
       [<c08b99ab>] ? printk+0x1d/0x22
       [<c0487752>] print_circular_bug+0xc2/0xd0
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c0478d81>] ? sched_clock_cpu+0x121/0x180
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
       [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c05ff314>] ? security_file_permission+0x14/0x20
       [<c0528242>] ? rw_verify_area+0x62/0xd0
       [<c052880f>] vfs_read+0x9f/0x190
       [<c047745b>] ? up_read+0x1b/0x30
       [<c057fdf0>] ? sysfs_read_file+0x0/0x190
       [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      7d47618a
    • Wey-Yi Guy's avatar
      iwlwifi: add name to Maintainers list · 9edc71b7
      Wey-Yi Guy authored
      Add "Wey-Yi Guy" to maintainers list for iwlwifi.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      9edc71b7
    • Abhijeet Kolekar's avatar
      iwl3945: fix internal scan · 14023641
      Abhijeet Kolekar authored
      Port of internal scan to iwl3945 missed introduction
      of iwl3945_get_single_channel_for_scan.
      
      Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208Signed-off-by: default avatarAbhijeet Kolekar <abhijeet.kolekar@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      14023641
    • Reinette Chatre's avatar
      iwl3945: enable stuck queue detection on 3945 · a6866ac9
      Reinette Chatre authored
      We learn from
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
      https://bugzilla.redhat.com/show_bug.cgi?id=589777
      that 3945 can also suffer from a stuck command queue. Enable stuck queue
      detection for iwl3945 to enable recovery in this case.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      a6866ac9
  15. 04 Jun, 2010 4 commits
  16. 01 Jun, 2010 3 commits
  17. 28 May, 2010 5 commits