Hi,
After upgrading to 3.4-rc5 from wireless-testing, one of my boxes fails to scan
and gets a "Network down" message for all wireless devices. The code in 3.4-rc4
was OK, thus I bisected to find the offending commit. The one that broke my
wireless is commit 3a25a8c entitled "mac80211: add improved HW queue control".
On my main laptop, this patch causes no problems. On a 3rd box, a BCM4312 (b43)
is OK, but an RTL8187L (rtl8187) also fails in the same manner.
The problem is not in the configuration as I copied the one from the box that
works to the one that fails, and it still fails. The only difference is that the
working system has 2 CPUs and the ones that fail are uni-processor; however, if
I boot with maxcpus=1, my main machine still works.
Any suggestions of things to try will be appreciated.
Larry
On Tue, 2012-05-08 at 12:00 +0300, Eliad Peller wrote:
> On Tue, May 8, 2012 at 11:32 AM, Eliad Peller <[email protected]> wrote:
> > On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <[email protected]> wrote:
> >>> > i'm not sure this is related to the problem you're facing, but the
> >>> > commit above seems to have some bug in which a packet might get
> >>> > enqueued on invalid queue (0xff) - please try this patch (compile
> >>> > tested only):
> >>
> >> Eliad, can you submit that patch with more details?
> >>
> > sure, i'll send it soon.
> >
> i've just figured it that it doesn't seem to have any effect, as the
> hw_queue will get overridden anyway in ieee80211_tx (because
> IEEE80211_HW_QUEUE_CONTROL is not set), so i'm not sure it's really
> needed. do you want me to send it anyway?
Still seems cleaner to me, I think
johannes
On 05/02/2012 07:58 AM, Eliad Peller wrote:
> hi Larry,
>
> On Tue, May 1, 2012 at 10:58 PM, Larry Finger<[email protected]> wrote:
>> After upgrading to 3.4-rc5 from wireless-testing, one of my boxes fails to
>> scan and gets a "Network down" message for all wireless devices. The code in
>> 3.4-rc4 was OK, thus I bisected to find the offending commit. The one that
>> broke my wireless is commit 3a25a8c entitled "mac80211: add improved HW
>> queue control".
>>
>> On my main laptop, this patch causes no problems. On a 3rd box, a BCM4312
>> (b43) is OK, but an RTL8187L (rtl8187) also fails in the same manner.
>>
>> The problem is not in the configuration as I copied the one from the box
>> that works to the one that fails, and it still fails. The only difference is
>> that the working system has 2 CPUs and the ones that fail are uni-processor;
>> however, if I boot with maxcpus=1, my main machine still works.
>>
>> Any suggestions of things to try will be appreciated.
>>
> i'm not sure this is related to the problem you're facing, but the
> commit above seems to have some bug in which a packet might get
> enqueued on invalid queue (0xff) - please try this patch (compile
> tested only):
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 3557354..ee815a9 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -2106,7 +2106,8 @@ static int ieee80211_mgmt_tx(struct wiphy
> *wiphy, struct net_device *dev,
>
> IEEE80211_SKB_CB(skb)->flags = flags;
>
> - if (flags& IEEE80211_TX_CTL_TX_OFFCHAN)
> + if (local->hw.flags& IEEE80211_HW_QUEUE_CONTROL&&
> + flags& IEEE80211_TX_CTL_TX_OFFCHAN)
> IEEE80211_SKB_CB(skb)->hw_queue =
> local->hw.offchannel_tx_hw_queue;
>
> @@ -2151,8 +2152,9 @@ static int ieee80211_mgmt_tx(struct wiphy
> *wiphy, struct net_device *dev,
> /* modify cookie to prevent API mismatches */
> *cookie ^= 2;
> IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_CTL_TX_OFFCHAN;
> - IEEE80211_SKB_CB(skb)->hw_queue =
> - local->hw.offchannel_tx_hw_queue;
> + if (local->hw.flags& IEEE80211_HW_QUEUE_CONTROL)
> + IEEE80211_SKB_CB(skb)->hw_queue =
> + local->hw.offchannel_tx_hw_queue;
> local->hw_roc_skb = skb;
> local->hw_roc_skb_for_status = skb;
> mutex_unlock(&local->mtx);
Sorry, but this patch does not fix my problem.
Larry
hi Larry,
On Tue, May 1, 2012 at 10:58 PM, Larry Finger <[email protected]> wrote:
> After upgrading to 3.4-rc5 from wireless-testing, one of my boxes fails to
> scan and gets a "Network down" message for all wireless devices. The code in
> 3.4-rc4 was OK, thus I bisected to find the offending commit. The one that
> broke my wireless is commit 3a25a8c entitled "mac80211: add improved HW
> queue control".
>
> On my main laptop, this patch causes no problems. On a 3rd box, a BCM4312
> (b43) is OK, but an RTL8187L (rtl8187) also fails in the same manner.
>
> The problem is not in the configuration as I copied the one from the box
> that works to the one that fails, and it still fails. The only difference is
> that the working system has 2 CPUs and the ones that fail are uni-processor;
> however, if I boot with maxcpus=1, my main machine still works.
>
> Any suggestions of things to try will be appreciated.
>
i'm not sure this is related to the problem you're facing, but the
commit above seems to have some bug in which a packet might get
enqueued on invalid queue (0xff) - please try this patch (compile
tested only):
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3557354..ee815a9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2106,7 +2106,8 @@ static int ieee80211_mgmt_tx(struct wiphy
*wiphy, struct net_device *dev,
IEEE80211_SKB_CB(skb)->flags = flags;
- if (flags & IEEE80211_TX_CTL_TX_OFFCHAN)
+ if (local->hw.flags & IEEE80211_HW_QUEUE_CONTROL &&
+ flags & IEEE80211_TX_CTL_TX_OFFCHAN)
IEEE80211_SKB_CB(skb)->hw_queue =
local->hw.offchannel_tx_hw_queue;
@@ -2151,8 +2152,9 @@ static int ieee80211_mgmt_tx(struct wiphy
*wiphy, struct net_device *dev,
/* modify cookie to prevent API mismatches */
*cookie ^= 2;
IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_CTL_TX_OFFCHAN;
- IEEE80211_SKB_CB(skb)->hw_queue =
- local->hw.offchannel_tx_hw_queue;
+ if (local->hw.flags & IEEE80211_HW_QUEUE_CONTROL)
+ IEEE80211_SKB_CB(skb)->hw_queue =
+ local->hw.offchannel_tx_hw_queue;
local->hw_roc_skb = skb;
local->hw_roc_skb_for_status = skb;
mutex_unlock(&local->mtx);
Eliad.
On Tue, May 8, 2012 at 11:32 AM, Eliad Peller <[email protected]> wrote:
> On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <[email protected]> wrote:
>>> > i'm not sure this is related to the problem you're facing, but the
>>> > commit above seems to have some bug in which a packet might get
>>> > enqueued on invalid queue (0xff) - please try this patch (compile
>>> > tested only):
>>
>> Eliad, can you submit that patch with more details?
>>
> sure, i'll send it soon.
>
i've just figured it that it doesn't seem to have any effect, as the
hw_queue will get overridden anyway in ieee80211_tx (because
IEEE80211_HW_QUEUE_CONTROL is not set), so i'm not sure it's really
needed. do you want me to send it anyway?
Eliad.
On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <[email protected]> wrote:
> On Wed, 2012-05-02 at 15:17 -0500, Larry Finger wrote:
>> >>
>> >> On my main laptop, this patch causes no problems. On a 3rd box, a BCM4312
>> >> (b43) is OK, but an RTL8187L (rtl8187) also fails in the same manner.
>
> Do you get the warning in iface.c:162 as well? It seems this would cause
> such problems.
>
>> > i'm not sure this is related to the problem you're facing, but the
>> > commit above seems to have some bug in which a packet might get
>> > enqueued on invalid queue (0xff) - please try this patch (compile
>> > tested only):
>
> Eliad, can you submit that patch with more details?
>
sure, i'll send it soon.
Eliad.
On Wed, 2012-05-02 at 15:17 -0500, Larry Finger wrote:
> >>
> >> On my main laptop, this patch causes no problems. On a 3rd box, a BCM4312
> >> (b43) is OK, but an RTL8187L (rtl8187) also fails in the same manner.
Do you get the warning in iface.c:162 as well? It seems this would cause
such problems.
> > i'm not sure this is related to the problem you're facing, but the
> > commit above seems to have some bug in which a packet might get
> > enqueued on invalid queue (0xff) - please try this patch (compile
> > tested only):
Eliad, can you submit that patch with more details?
johannes