* Wireless problem in 3.4-rc5 @ 2012-05-01 19:58 Larry Finger 2012-05-02 12:58 ` Eliad Peller 0 siblings, 1 reply; 7+ messages in thread From: Larry Finger @ 2012-05-01 19:58 UTC (permalink / raw) To: Johannes Berg; +Cc: John Linville, wireless 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-01 19:58 Wireless problem in 3.4-rc5 Larry Finger @ 2012-05-02 12:58 ` Eliad Peller 2012-05-02 20:17 ` Larry Finger 0 siblings, 1 reply; 7+ messages in thread From: Eliad Peller @ 2012-05-02 12:58 UTC (permalink / raw) To: Larry Finger; +Cc: Johannes Berg, John Linville, wireless hi Larry, On Tue, May 1, 2012 at 10:58 PM, Larry Finger <Larry.Finger@lwfinger.net> 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. ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-02 12:58 ` Eliad Peller @ 2012-05-02 20:17 ` Larry Finger 2012-05-07 11:30 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Larry Finger @ 2012-05-02 20:17 UTC (permalink / raw) To: Eliad Peller; +Cc: Johannes Berg, John Linville, wireless On 05/02/2012 07:58 AM, Eliad Peller wrote: > hi Larry, > > On Tue, May 1, 2012 at 10:58 PM, Larry Finger<Larry.Finger@lwfinger.net> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-02 20:17 ` Larry Finger @ 2012-05-07 11:30 ` Johannes Berg 2012-05-08 8:32 ` Eliad Peller 0 siblings, 1 reply; 7+ messages in thread From: Johannes Berg @ 2012-05-07 11:30 UTC (permalink / raw) To: Larry Finger; +Cc: Eliad Peller, John Linville, wireless 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-07 11:30 ` Johannes Berg @ 2012-05-08 8:32 ` Eliad Peller 2012-05-08 9:00 ` Eliad Peller 0 siblings, 1 reply; 7+ messages in thread From: Eliad Peller @ 2012-05-08 8:32 UTC (permalink / raw) To: Johannes Berg; +Cc: Larry Finger, John Linville, wireless On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <johannes@sipsolutions.net> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-08 8:32 ` Eliad Peller @ 2012-05-08 9:00 ` Eliad Peller 2012-05-08 10:57 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Eliad Peller @ 2012-05-08 9:00 UTC (permalink / raw) To: Johannes Berg; +Cc: Larry Finger, John Linville, wireless On Tue, May 8, 2012 at 11:32 AM, Eliad Peller <eliad@wizery.com> wrote: > On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <johannes@sipsolutions.net> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wireless problem in 3.4-rc5 2012-05-08 9:00 ` Eliad Peller @ 2012-05-08 10:57 ` Johannes Berg 0 siblings, 0 replies; 7+ messages in thread From: Johannes Berg @ 2012-05-08 10:57 UTC (permalink / raw) To: Eliad Peller; +Cc: Larry Finger, John Linville, wireless On Tue, 2012-05-08 at 12:00 +0300, Eliad Peller wrote: > On Tue, May 8, 2012 at 11:32 AM, Eliad Peller <eliad@wizery.com> wrote: > > On Mon, May 7, 2012 at 2:30 PM, Johannes Berg <johannes@sipsolutions.net> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-05-08 10:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-01 19:58 Wireless problem in 3.4-rc5 Larry Finger 2012-05-02 12:58 ` Eliad Peller 2012-05-02 20:17 ` Larry Finger 2012-05-07 11:30 ` Johannes Berg 2012-05-08 8:32 ` Eliad Peller 2012-05-08 9:00 ` Eliad Peller 2012-05-08 10:57 ` Johannes Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).