1. 26 3月, 2010 2 次提交
  2. 20 3月, 2010 3 次提交
  3. 10 3月, 2010 8 次提交
  4. 03 3月, 2010 1 次提交
    • J
      iwlwifi: load firmware asynchronously before mac80211 registration · b08dfd04
      Johannes Berg 提交于
      At the wireless summit in Portland we discussed a way of
      loading firmware asynchronously from ->probe() before
      registration to mac80211, in order to register with the
      wireless subsystems with complete information in cases
      where firmware is required to know parameters.
      
      This is not yet the case in iwlwifi, but for some new
      features we're working on it will be the case since
      those will only be supported by new firmware images.
      
      Hence, to start with, convert iwlwifi to load firmware
      asynchronously from probe, unbinding the device when
      firmware loading fails, and only registering with the
      wireless subsystems after firmware has been loaded
      successfully.
      
      Future patches will hook into this to register the
      new firmware capabilities, depending on the firmware
      API version.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b08dfd04
  5. 24 2月, 2010 1 次提交
    • R
      Revert "iwlwifi: Monitor and recover the aggregation TX flow failure" · ab9bdc34
      Reinette Chatre 提交于
      This reverts commit 1db5950f.
      
      The goal of "iwlwifi: Monitor and recover the aggregation TX flow failure"
      is to first detect when data transmission stalls and then to recover from
      this situation with a reset of the radio or the firmware, depending on how
      bad the transmission failures are.
      
      Unfortunately we have found that this change causes excessive resets with
      its current detection algorithm. It also performs its recovery action when
      none is really needed, like when we are not associated.
      
      Revert this change until the issues have been addressed.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      ab9bdc34
  6. 20 2月, 2010 2 次提交
  7. 12 2月, 2010 3 次提交
  8. 30 1月, 2010 2 次提交
  9. 26 1月, 2010 7 次提交
  10. 20 1月, 2010 3 次提交
  11. 09 1月, 2010 1 次提交
    • Z
      iwlwifi: fix iwl_queue_used bug when read_ptr == write_ptr · c8106d76
      Zhu Yi 提交于
      When txq read_ptr equals to write_ptr, iwl_queue_used should
      always return false. Because there is no used TFD in this case.
      
      This is a complementary fix to the fix already included in commit "iwl3945:
      fix panic in iwl3945 driver". Both fixes are needed to address the panic
      below.
      
      This problem was discussed on linux-wireless in
      http://thread.gmane.org/gmane.linux.kernel.wireless.general/43568
      
      <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
      <4>[ 7290.414205] PGD 0
      <1>[ 7290.414214] Thread overran stack, or stack corrupted
      <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
      <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
      <4>[ 7290.414265] CPU 0
      <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
      <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P           2.6.32-rc8-wl #213 Aspire 5720
      <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>]  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
      <6>[ 7290.414541] RSP: 0018:ffff880002203d60  EFLAGS: 00010246
      <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013
      <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038
      <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100
      <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0
      <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201
      <6>[ 7290.414655] FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
      <6>[ 7290.414677] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0
      <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60)
      <0>[ 7290.414772] Stack:
      <4>[ 7290.414780]  ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
      <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
      <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
      <0>[ 7290.414858] Call Trace:
      <0>[ 7290.414867]  <IRQ>
      <4>[ 7290.414884]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
      <4>[ 7290.414910]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
      <4>[ 7290.414931]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
      <4>[ 7290.414950]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
      <4>[ 7290.414968]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
      <4>[ 7290.414986]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
      <4>[ 7290.415003]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
      <4>[ 7290.415020]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
      <4>[ 7290.415038]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
      <0>[ 7290.415052]  <EOI>
      <4>[ 7290.415067]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
      <4>[ 7290.415087]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
      <4>[ 7290.415107]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
      <4>[ 7290.415130]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
      <4>[ 7290.415149]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
      <4>[ 7290.415168]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
      <4>[ 7290.415187]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
      <4>[ 7290.415206]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
      <4>[ 7290.415227]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
      <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
      <1>[ 7290.415382] RIP  [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
      <4>[ 7290.415410]  RSP <ffff880002203d60>
      <0>[ 7290.415421] CR2: 0000000000000041
      <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]---
      <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
      <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P      D    2.6.32-rc8-wl #213
      <4>[ 7290.415486] Call Trace:
      <4>[ 7290.415495]  <IRQ>  [<ffffffff8138c040>] panic+0x7d/0x13a
      <4>[ 7290.415519]  [<ffffffff8101071a>] oops_end+0xda/0xe0
      <4>[ 7290.415538]  [<ffffffff8102e1ea>] no_context+0xea/0x250
      <4>[ 7290.415557]  [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
      <4>[ 7290.415578]  [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
      <4>[ 7290.415597]  [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
      <4>[ 7290.415616]  [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
      <4>[ 7290.415636]  [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
      <4>[ 7290.415656]  [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320
      <4>[ 7290.415674]  [<ffffffff813905df>] page_fault+0x1f/0x30
      <4>[ 7290.415697]  [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
      <4>[ 7290.415723]  [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
      <4>[ 7290.415746]  [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
      <4>[ 7290.415764]  [<ffffffff81049a21>] tasklet_action+0x101/0x110
      <4>[ 7290.415783]  [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160
      <4>[ 7290.415801]  [<ffffffff8100d01c>] call_softirq+0x1c/0x30
      <4>[ 7290.415818]  [<ffffffff8100eff5>] do_softirq+0x75/0xb0
      <4>[ 7290.415835]  [<ffffffff81049ee5>] irq_exit+0x95/0xa0
      <4>[ 7290.415852]  [<ffffffff8100e547>] do_IRQ+0x77/0xf0
      <4>[ 7290.415869]  [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf
      <4>[ 7290.415883]  <EOI>  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
      <4>[ 7290.415911]  [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
      <4>[ 7290.415931]  [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
      <4>[ 7290.415952]  [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
      <4>[ 7290.415971]  [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
      <4>[ 7290.415989]  [<ffffffff8137b3d5>] ? rest_init+0x75/0x80
      <4>[ 7290.416007]  [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
      <4>[ 7290.416026]  [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
      <4>[ 7290.416047]  [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
      Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      CC: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c8106d76
  12. 23 12月, 2009 1 次提交
  13. 22 12月, 2009 3 次提交
    • W
      iwlwifi: add continuous uCode event log capability · a9e1cb6a
      Wey-Yi Guy 提交于
      In order to help uCode debugging, adding the capability to provide
      continuous uCode event logging function.
      
      uCode events is located in round-robin event queue and filled by uCode,
      by enable continuous event logging, driver check the write pointer
      and log the newly added events in iwl_bg_ucode_trace() timer function.
      
      There is still possibility of missing events if event queue being
      wrapped before next event dump; but with this capability, we can have
      much better understanding of the uCode behavior during runtime; it can
      help to debug the uCode related issues.
      
      Methods to enable/disable the continuous event log:
      step 1: enable ucode trace timer
           "echo 1 >
      /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
      step 2: start ftrace
           sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d
      step 3: stop ftrace
           sudo ./trace-cmd report trace.dat
      step 4: disable ucode trace timer
           "echo 0 >
      /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
      
      use "ucode_tracing" debugfs file to display number of event
      queue wrapped when driver attempt the continuous event logging. If event
      queue being wrapped more than once when driver has opportunity to log
      the event; it indicated there are events missing in the event log trace.
      
      This continuous event log function only available for 4965 and newer
      NICs.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a9e1cb6a
    • J
      iwlwifi: fix EEPROM/OTP reading endian annotations and a bug · af6b8ee3
      Johannes Berg 提交于
      The construct "le16_to_cpu((__force __le16)(r >> 16))" has
      always bothered me when looking through the iwlwifi code,
      it shouldn't be necessary to __force anything, and before
      this code, "r" was obtained with an ioread32, which swaps
      each of the two u16 values in it properly when swapping the
      entire u32 value. I've had arguments about this code with
      people before, but always conceded they were right because
      removing it only made things not work at all on big endian
      platforms.
      
      However, analysing a failure of the OTP reading code, I now
      finally figured out what is going on, and why my intuition
      about that code being wrong was right all along.
      
      It turns out that the 'priv->eeprom' u8 array really wants
      to have the data in it in little endian. So the force code
      above and all really converts *to* little endian, not from
      it. Cf., for instance, the function iwl_eeprom_query16() --
      it reads two u8 values and combines them into a u16, in a
      little-endian way. And considering it more, it makes sense
      to have the eeprom array as on the device, after all not
      all values really are 16-bit values, the MAC address for
      instance is not.
      
      Now, what this really means is that all the annotations are
      completely wrong. The eeprom reading code should fill the
      priv->eeprom array as a __le16 array, with __le16 values.
      
      This also means that iwl_read_otp_word() should really have
      a __le16 pointer as the data argument, since it should be
      filling that in a format suitable for priv->eeprom.
      
      Propagating these changes throughout, iwl_find_otp_image()
      is found to be, now obviously visible, defective -- it uses
      the data returned by iwl_read_otp_word() directly as if it
      was CPU endianness. Fixing that, which is this hunk of the
      patch:
      
      -               next_link_addr = link_value * sizeof(u16);
      +               next_link_addr = le16_to_cpu(link_value) * sizeof(u16);
      
      is the only real change of this patch. Everything else is
      just fixing the sparse annotations.
      
      Also, the bug only shows up on big endian platforms with a
      1000 series card. 5000 and previous series do not use OTP,
      and 6000 series has shadow RAM support which means we don't
      ever use the defective code on any cards but 1000.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af6b8ee3
    • Z
      iwlwifi: allocated rx page accounting cleanup · 64a76b50
      Zhu Yi 提交于
      In iwlwifi, priv->alloc_rxb_page is used to keep track of the Rx
      pages allocated by the driver. This cleans up the page free routines
      by introducing __iwl_free_pages/iwl_free_pages so that the accounting
      is more accurate and less error prone. This also fixes two instances where
      the counter was not updated.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64a76b50
  14. 24 11月, 2009 3 次提交