Zhu Yi | 1 Jun 03:01 2007
Picon

Re: [TAKE 2][PATCH 0/3] IEEE802.11e/WMM TS management and DLS support

On Thu, 2007-05-31 at 14:04 -0400, John W. Linville wrote:
> Please also submit a patch series that applies against
> linux-2.6.22-rc3 (or later) and adds whatever else might be needed
> that is missing there.  This one changes code that is currently only
> in wireless-dev. 

Thanks! Will do.

-yi
Zhu Yi | 1 Jun 03:04 2007
Picon

Re: [TAKE 2][PATCH 0/3] IEEE802.11e/WMM TS management and DLS support

On Thu, 2007-05-31 at 12:55 -0700, Michael Wu wrote:
> This is nowhere near ready to go upstream and it requires some bits
> from the 802.11n patches which didn't make it. 

Can you speak what is needed for 11n and where to find the 11n patches?

Thanks,
-yi
Michael Buesch | 1 Jun 11:29 2007
Picon

[PATCH] mac80211: Update stop_queues kdoc

This updates stop_queue(s) kdoc as currently there's
a undocumented dependency.

Stopping the queue from anywhere else than the ops->tx()
callback will result in a hard to debug deadlock and
system freeze (on UP).

Here's an example stacktrace that has been captured only
by special debugging patches to the PPC-decrementer to
detect this machine freeze.
http://bu3sch.de/misc/freeze1.jpg
http://bu3sch.de/misc/freeze2.jpg

Signed-off-by: Michael Buesch <mb@...>

Index: mac80211/include/net/mac80211.h
===================================================================
--- mac80211.orig/include/net/mac80211.h	2007-06-01 11:20:32.000000000 +0200
+++ mac80211/include/net/mac80211.h	2007-06-01 11:23:02.000000000 +0200
 <at>  <at>  -967,6 +967,10  <at>  <at>  void ieee80211_wake_queue(struct ieee802
  *  <at> queue: queue number (counted from zero).
  *
  * Drivers should use this function instead of netif_stop_queue.
+ *
+ * It's currently only safe to call this function from the
+ * ops->tx() callback. Calls from elsewhere will result in
+ * hard to debug deadlocks (freezes the system on UP).
  */
 void ieee80211_stop_queue(struct ieee80211_hw *hw, int queue);

(Continue reading)

Johannes Berg | 1 Jun 11:48 2007
Picon

Re: [PATCH] mac80211: Update stop_queues kdoc

On Fri, 2007-06-01 at 11:29 +0200, Michael Buesch wrote:
> This updates stop_queue(s) kdoc as currently there's
> a undocumented dependency.
> 
> Stopping the queue from anywhere else than the ops->tx()
> callback will result in a hard to debug deadlock and
> system freeze (on UP).

Ugh. Any way to actually detect a wrong spot to call it at runtime?

johannes
Michael Buesch | 1 Jun 11:53 2007
Picon

Re: [PATCH] mac80211: Update stop_queues kdoc

On Friday 01 June 2007 11:48:11 Johannes Berg wrote:
> On Fri, 2007-06-01 at 11:29 +0200, Michael Buesch wrote:
> > This updates stop_queue(s) kdoc as currently there's
> > a undocumented dependency.
> > 
> > Stopping the queue from anywhere else than the ops->tx()
> > callback will result in a hard to debug deadlock and
> > system freeze (on UP).
> 
> Ugh. Any way to actually detect a wrong spot to call it at runtime?

Probably by verifying if netif_tx_lock is locked somehow.
But I'm not sure.

--

-- 
Greetings Michael.
Olivier Cornu | 1 Jun 13:55 2007
Picon

Re: [PATCH] mac80211: Update stop_queues kdoc

2007/6/1, Michael Buesch <mb@...>:
> This updates stop_queue(s) kdoc as currently there's
> a undocumented dependency.
>
> Stopping the queue from anywhere else than the ops->tx()
> callback will result in a hard to debug deadlock and
> system freeze (on UP).

Sorry but: why would one call ieee80211_stop_queue() from outside of
the tx handler in the first place? Wouldn't that simply be a driver
design problem?
Unless i missed something, stop_queue() isn't called outside of the tx
handler in bcm43xx code...

--
Olivier Cornu
Michal Piotrowski | 1 Jun 14:20 2007
Picon

[1/3] 2.6.22-rc3: known regressions v2

Hi all,

Here is a list of some known regressions in 2.6.22-rc3.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

Unclassified

Subject    : build failed in function `vic_sys_interrupt'
References : http://lkml.org/lkml/2007/5/31/227
Submitter  : Toralf Förster <toralf.foerster@...>
Status     : Unknown

Subject    : long freezes on thinkpad t60
References : http://lkml.org/lkml/2007/5/24/100
Submitter  : Miklos Szeredi <miklos@...>
Handled-By : Ingo Molnar <mingo@...>
Status     : problem is being debugged

ACPI

Subject    : unable to shutdown on kernel 2.6.22-rc2
References : http://bugzilla.kernel.org/show_bug.cgi?id=8516
Submitter  : Thierry Volpiatto <tvolpiatt@...>
Status     : Unknown

ALSA

Subject    : snd-aoa causes badness in lib/kref.c:33
(Continue reading)

Larry Finger | 1 Jun 17:59 2007
Picon

Re: [PATCH] softmac: use list_for_each_entry

Johannes,

Johannes Berg wrote:
> On Sun, 2007-05-27 at 23:27 +0900, Akinobu Mita wrote:
>> Cleanup using list_for_each_entry.
> 
>> This patch adds missing NULL check and trims a line longer than 80
>> columns.
> 
> Both patches look good to me but I do wonder why you're actually looking
> at this code :)
> 
> I sure hope somebody will port bcm43xx driver to mac80211 (again) soon
> so we can remove softmac.

As it is impossible to predict how long until we can remove softmac, such patches should be 
accepted. You understand that I'm not looking for problems in softmac.

As we discussed earlier, bcm43xx-softmac has to be ported to mac80211 to support 802.11b-only cards, 
as the V4 firmware does not accommodate them. I had started this project by changing the namespace 
to bcm4301. That patch went into Linville's wireless-dev pending list. I then started learning the 
interface to mac80211. For a number of reasons, that step was going slowly. Michael Wu recently 
offered to take over, which seemed reasonable given his familiarity with mac80211.

When Michael Wu gets a version of bcm4301-mac80211 that compiles cleanly, I will be testing it as he 
doesn't have the hardware. For my testing purposes, the 802.11g stuff will still be there. Once I 
get it working, I plan to post a patch to get as much testing as possible.

In the earlier discussion, we also concluded that the product of a conversion from softmac to 
mac80211 should not be included in mainline, with the exception of the b-only code. Depending on how 
(Continue reading)

Larry Finger | 1 Jun 18:14 2007
Picon

mac80211 initial rate: a question

In routine rate_control_simple_rate_init in net/mac80211/rc80211_simple.c, there is a comment that says

         /* TODO: what is a good starting rate for STA? About middle? Maybe not
          * the lowest or the highest rate.. Could consider using RSSI from
          * previous packets? Need to have IEEE 802.1X auth succeed immediately
          * after assoc.. */

After that the code goes on to set the rate equal to the last one in the rate table, which might be 
the highest rate. Although that rate might be OK for most of the devices using mac80211, it 
certainly is not for bcm43xx, which does not have the ability to transmit or receive at speeds much 
above 1 Mbs. In a private patch circulated only on the bcm43xx mailing list, I changed this routine 
to set an initial rate of 1 Mbs, which certainly helps bcm43xx authenticate and communicate with the 
DHCP server.

If this low rate were to be set for all drivers, how rapidly would the rate-control algorithm 
respond? Would this cause a serious performance degradation?

Larry
Larry Finger | 1 Jun 19:55 2007
Picon

Locking problem in bcm43xx-mac80211

When a 'modprobe -r bcm43xx-mac80211' command is given with the interface up, the following kernel 
BUG is issued:

ssb: Switching to ChipCommon core, index 0
ssb: Switching to IEEE 802.11 core, index 1
bcm43xx_mac80211: Radio turned off
BUG: sleeping function called from invalid context at kernel/mutex.c:86
in_atomic():1, irqs_disabled():0
2 locks held by modprobe/6053:
  #0:  (rtnl_mutex){--..}, at: [<ffffffff803f0d63>] mutex_lock+0x2a/0x2e
  #1:  (&local->sta_lock){-+..}, at: [<ffffffff882622a5>] sta_info_flush+0x20/0x77 [mac80211]

Call Trace:
  [<ffffffff8024c830>] debug_show_held_locks+0x22/0x24
  [<ffffffff8022ab32>] __might_sleep+0xd9/0xdb
  [<ffffffff803f0d56>] mutex_lock+0x1d/0x2e
  [<ffffffff8829dc3a>] :bcm43xx_mac80211:bcm43xx_dev_set_key+0xc3/0x2e4
  [<ffffffff8028eea5>] __kmalloc+0x17e/0x18e
  [<ffffffff882621bf>] :mac80211:sta_info_free+0xec/0x1b2
  [<ffffffff882622cf>] :mac80211:sta_info_flush+0x4a/0x77
  [<ffffffff8826c5bf>] :mac80211:ieee80211_if_reinit+0x29c/0x2c7
  [<ffffffff80398de0>] unregister_netdevice+0x17e/0x201
  [<ffffffff8826bd06>] :mac80211:__ieee80211_if_del+0x1d/0x21
  [<ffffffff8825a985>] :mac80211:ieee80211_unregister_hw+0xbc/0x216
  [<ffffffff8829cf95>] :bcm43xx_mac80211:bcm43xx_remove+0x53/0x7f
  [<ffffffff8828f23b>] :ssb:ssb_device_remove+0x2b/0x39
  [<ffffffff8036cab5>] __device_release_driver+0x93/0xb3
  [<ffffffff8036d03d>] driver_detach+0xdb/0x11e
  [<ffffffff8036c529>] bus_remove_driver+0x75/0x97
  [<ffffffff8036d0b1>] driver_unregister+0x9/0xb
(Continue reading)


Gmane