Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 8月, 2009 1 次提交
  3. 14 8月, 2009 4 次提交
  5. 05 8月, 2009 1 次提交
  7. 25 7月, 2009 2 次提交
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      由 Reinette Chatre 提交于 
      * Deprecate the "debug50" module parameter used to obtain
  5000 series and up debugging. Replace it with "debug" module
  parameter to match with original driver and be consistent
  between them. The "debug50" module parameter can still be used,
  except that the module parameter is not writable in keeping
  with its previous state. We currently just mark it as "deprecated"
  and do not have it in the feature-removal-schedule. Some more
  cleanup of module parameters needs to be done and can then be
  entered together.

* Only make "debug" module parameters visible if the driver
  is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
  a lot of confusion where users think they have set debug flags
  but yet cannot see any debug output.

* Make module parameters writable. This eliminates the need for the
  "debug_level" sysfs file, which can now also be deprecated and
  added to feature-removal-schedule. This file is in significant
  use though with many iwlwifi documents and text referring users
  to it. We can thus not take its removal lightly and keep it around.

With iwlcore shared between iwlagn and iwl3945 we really do not need
debug module parameters for each but can instead have one debug
module parameter for the iwlcore module. The same issue is here as
with the sysfs file - a lot of iwlwifi documentation and text (like
bug reports) rely on iwlagn and iwl3945 having this module parameter,
so changing this to a module parameter of iwlcore will have significant
impact and we do not do this for that reason.

One consequence of this patch is that if a user is running a system
with both 3945 and later hardware then the setting of the one module
parameter will affect the value of the other. The likelihood of this
seems low - and even if this setup is present it does not seem like an
issue for both modules to run with the same debug level.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
    • W
      iwlwifi: fix rx signal quality reporting in dmesg · 244294e8
      由 Wey-Yi Guy 提交于 
      Fix quality incorrectly reported as signal strength value.
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>
      244294e8
  9. 11 7月, 2009 2 次提交
  11. 23 5月, 2009 4 次提交
  13. 23 4月, 2009 1 次提交
  15. 10 2月, 2009 2 次提交
  17. 30 1月, 2009 5 次提交
  19. 20 12月, 2008 1 次提交
    • Z
      iwlwifi: use GFP_KERNEL to allocate Rx SKB memory · f1bc4ac6
      由 Zhu Yi 提交于 
      Previously we allocate Rx SKB with GFP_ATOMIC flag. This is because we need
to hold a spinlock to protect the two rx_used and rx_free lists operation
in the rxq.

	spin_lock();
	...
	element = rxq->rx_used.next;
	element->skb = alloc_skb(..., GFP_ATOMIC);
	list_del(element);
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

After spliting the rx_used delete and rx_free insert into two operations,
we don't require the skb allocation in an atomic context any more (the
function itself is scheduled in a workqueue).

	spin_lock();
	...
	element = rxq->rx_used.next;
	list_del(element);
	...
	spin_unlock();
	...
	element->skb = alloc_skb(..., GFP_KERNEL);
	...
	spin_lock()
	...
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

This patch should fix the "iwlagn: Can not allocate SKB buffers" warning
we see recently.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1bc4ac6
  21. 13 12月, 2008 7 次提交
  23. 26 11月, 2008 1 次提交
  25. 22 11月, 2008 2 次提交
  27. 19 11月, 2008 1 次提交
    • J
      iwlagn: fix RX skb alignment · 4018517a
      由 Johannes Berg 提交于 
      So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:

	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));

Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)

After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it,  because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.

So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.

This should fix the following reported kernel bugs:

http://bugzilla.kernel.org/show_bug.cgi?id=11596
http://bugzilla.kernel.org/show_bug.cgi?id=11393
http://bugzilla.kernel.org/show_bug.cgi?id=11983

I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...

I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.

I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4018517a
  29. 01 11月, 2008 1 次提交
  31. 01 10月, 2008 1 次提交
  33. 16 9月, 2008 1 次提交
  35. 04 9月, 2008 1 次提交
  37. 23 8月, 2008 1 次提交
  39. 05 8月, 2008 1 次提交