On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
> Hi guys,
>
> Starting with 3.10.6 (and still present in .7) I get an oops on
> connecting to the network.
>
> The attached picture shows the oops. In case it does not reach the ML,
> the top of the call trace reads:
>
> brcms_c_compute_rtscts_dur
> brcms_c_ampdu_finalize
> ampdu_finalize
> dma_txfast
> brcms_c_txfifo
> brcms_c_sendpkt_mac80211
> brcms_ops_tx
> __ieee80211_tx
>
> I bisected the problem and the first bad commit is
>
> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
> Author: Felix Fietkau <[email protected]>
> Date: Fri Jun 28 21:04:35 2013 +0200
>
> mac80211/minstrel_ht: fix cck rate sampling
>
> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>
> Reverting it on top of .7 fixes the problem.
>
> I had the same (I suppose) problem on mainline some time ago, but I
> have not bisected it, verified that the problem still occurs there, or
> checked if reverting the upstream patch fixes it. I'd be happy to do
> that if it would help though.
>
> Let me know if you need any more information.
Do you have this same problem with 3.11-rc6 as well?
thanks,
greg k-h
On Tue, Aug 20, 2013 at 12:56 PM, Felix Fietkau <[email protected]> wrote:
> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>> <[email protected]> wrote:
>>> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>> >> Hi guys,
>>> >>
>>> >> Starting with 3.10.6 (and still present in .7) I get an oops on
>>> >> connecting to the network.
>>> >>
>>> >> The attached picture shows the oops. In case it does not reach the ML,
>>> >> the top of the call trace reads:
>>> >>
>>> >> brcms_c_compute_rtscts_dur
>>> >> brcms_c_ampdu_finalize
>>> >> ampdu_finalize
>>> >> dma_txfast
>>> >> brcms_c_txfifo
>>> >> brcms_c_sendpkt_mac80211
>>> >> brcms_ops_tx
>>> >> __ieee80211_tx
>>> >>
>>> >> I bisected the problem and the first bad commit is
>>> >>
>>> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>> >> Author: Felix Fietkau <[email protected]>
>>> >> Date: Fri Jun 28 21:04:35 2013 +0200
>>> >>
>>> >> mac80211/minstrel_ht: fix cck rate sampling
>>> >>
>>> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>> >>
>>> >> Reverting it on top of .7 fixes the problem.
>>> >>
>>> >> I had the same (I suppose) problem on mainline some time ago, but I
>>> >> have not bisected it, verified that the problem still occurs there, or
>>> >> checked if reverting the upstream patch fixes it. I'd be happy to do
>>> >> that if it would help though.
>>> >>
>>> >> Let me know if you need any more information.
>>> >
>>> > Do you have this same problem with 3.11-rc6 as well?
>>>
>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>> commit on top of -rc6 fixes the problem.
>>
>> Great, thanks.
>>
>> Felix and Johannes, any chance we can get this reverted in Linus tree
>> soon, and push that revert back to the 3.10 stable tree as well?
> I'd like to avoid a revert, since that will simply replace one set of
> issues with another. Let's limit the use of the feature that brcmsmac
> can't handle to drivers that are known to work with it. Tom, Please
> test this patch to see if it fixes your issue.
The patch (on top of -rc6) fixes it for me. Thanks.
-t
> ---
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24,
> IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25,
> IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27,
> };
>
> /**
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
> if (sband->band != IEEE80211_BAND_2GHZ)
> return;
>
> + if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
> + return;
> +
> mi->cck_supported = 0;
> mi->cck_supported_short = 0;
> for (i = 0; i < 4; i++) {
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_SPECTRUM_MGMT |
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> - IEEE80211_HW_SUPPORTS_RC_TABLE;
> + IEEE80211_HW_SUPPORTS_RC_TABLE |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
> IEEE80211_HW_SUPPORTS_RC_TABLE |
> - IEEE80211_HW_SIGNAL_DBM;
> + IEEE80211_HW_SIGNAL_DBM |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (!modparam_noht) {
> /*
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_AMPDU_AGGREGATION |
> - IEEE80211_HW_REPORTS_TX_ACK_STATUS;
> + IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> /*
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
>
I verify the same issue on a Latitude E6520 running both the
vanilla/clean and the Fedora 19 specific kernels. I thought it was the
NVIDIA/nouveau driver and I reproduce by switching to non graphical mode
and performing scp transfers.
GM
On Tue, 2013-08-20 at 11:58 +0200, Arend van Spriel wrote:
> On 08/20/2013 10:36 AM, Tom Gundersen wrote:
> > On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel <[email protected]> wrote:
> >> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
> >>>
> >>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
> >>>>
> >>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
> >>>>>
> >>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
> >>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
> >>>>>>>
> >>>>>>> Hi guys,
> >>>>>>>
> >>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
> >>>>>>> connecting to the network.
> >>>>>>>
> >>>>>>> The attached picture shows the oops. In case it does not reach the ML,
> >>>>>>> the top of the call trace reads:
> >>>>>>>
> >>>>>>> brcms_c_compute_rtscts_dur
> >>>>>>> brcms_c_ampdu_finalize
> >>>>>>> ampdu_finalize
> >>>>>>> dma_txfast
> >>>>>>> brcms_c_txfifo
> >>>>>>> brcms_c_sendpkt_mac80211
> >>>>>>> brcms_ops_tx
> >>>>>>> __ieee80211_tx
> >>>>>>>
> >>>>>>> I bisected the problem and the first bad commit is
> >>>>>>>
> >>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
> >>>>>>> Author: Felix Fietkau <[email protected]>
> >>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
> >>>>>>>
> >>>>>>> mac80211/minstrel_ht: fix cck rate sampling
> >>>>>>>
> >>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
> >>>>>>>
> >>>>>>> Reverting it on top of .7 fixes the problem.
> >>>>>>>
> >>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
> >>>>>>> have not bisected it, verified that the problem still occurs there, or
> >>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
> >>>>>>> that if it would help though.
> >>>>>>>
> >>>>>>> Let me know if you need any more information.
> >>>>>>
> >>>>>>
> >>>>>> Do you have this same problem with 3.11-rc6 as well?
> >>>>>
> >>>>>
> >>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
> >>>>> commit on top of -rc6 fixes the problem.
> >>>>
> >>>>
> >>>> Great, thanks.
> >>>>
> >>>> Felix and Johannes, any chance we can get this reverted in Linus tree
> >>>> soon, and push that revert back to the 3.10 stable tree as well?
> >>>
> >>> I'd like to avoid a revert, since that will simply replace one set of
> >>> issues with another. Let's limit the use of the feature that brcmsmac
> >>> can't handle to drivers that are known to work with it. Tom, Please
> >>> test this patch to see if it fixes your issue.
> >>
> >>
> >> Hi Felix,
> >>
> >> I have been diving into root causing why brcmsmac can not handle cck
> >> fallback rates, because it should. Maybe it is better to flag no cck support
> >> and only change brcmsmac.
> >
> > Hi Arend,
> >
> > In case you cannot reproduce, let me know if I can help with testing patches.
>
> So far I have not been able to reproduce it. I have a patch to avoid the
> oops, but the transmit of the related frames will fail in the device so
> it is not a real fix. I will let you you know.
>
> Regards,
> Arend
>
> > Cheers,
> >
> > Tom
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>> >> Hi guys,
>> >>
>> >> Starting with 3.10.6 (and still present in .7) I get an oops on
>> >> connecting to the network.
>> >>
>> >> The attached picture shows the oops. In case it does not reach the ML,
>> >> the top of the call trace reads:
>> >>
>> >> brcms_c_compute_rtscts_dur
>> >> brcms_c_ampdu_finalize
>> >> ampdu_finalize
>> >> dma_txfast
>> >> brcms_c_txfifo
>> >> brcms_c_sendpkt_mac80211
>> >> brcms_ops_tx
>> >> __ieee80211_tx
>> >>
>> >> I bisected the problem and the first bad commit is
>> >>
>> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>> >> Author: Felix Fietkau <[email protected]>
>> >> Date: Fri Jun 28 21:04:35 2013 +0200
>> >>
>> >> mac80211/minstrel_ht: fix cck rate sampling
>> >>
>> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>> >>
>> >> Reverting it on top of .7 fixes the problem.
>> >>
>> >> I had the same (I suppose) problem on mainline some time ago, but I
>> >> have not bisected it, verified that the problem still occurs there, or
>> >> checked if reverting the upstream patch fixes it. I'd be happy to do
>> >> that if it would help though.
>> >>
>> >> Let me know if you need any more information.
>> >
>> > Do you have this same problem with 3.11-rc6 as well?
>>
>> Yes, I just confirmed. I also confirmed that reverting the mainline
>> commit on top of -rc6 fixes the problem.
>
> Great, thanks.
>
> Felix and Johannes, any chance we can get this reverted in Linus tree
> soon, and push that revert back to the 3.10 stable tree as well?
I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.
- Felix
---
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24,
IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25,
IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27,
};
/**
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
if (sband->band != IEEE80211_BAND_2GHZ)
return;
+ if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+ return;
+
mi->cck_supported = 0;
mi->cck_supported_short = 0;
for (i = 0; i < 4; i++) {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
- IEEE80211_HW_SUPPORTS_RC_TABLE;
+ IEEE80211_HW_SUPPORTS_RC_TABLE |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
IEEE80211_HW_SUPPORTS_RC_TABLE |
- IEEE80211_HW_SIGNAL_DBM;
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (!modparam_noht) {
/*
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
/*
* Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
On 2013-08-20 10:15 AM, Arend van Spriel wrote:
> Hi Felix,
>
> I have been diving into root causing why brcmsmac can not handle cck
> fallback rates, because it should. Maybe it is better to flag no cck
> support and only change brcmsmac.
I prefer having a flag to enable it over one to disable it, because it
fits better with the existing flags. Also, future drivers may not always
be properly prepared to handle CCK in A-MPDU sessions either.
By the way, I took a short look at brcmsmac and found more issues that
you should look into if you want to fix this.
First of all, you should probably make sure that the hardware does not
try to send an A-MPDU using a CCK rate (prepare it as a single frame in
brcms_c_ampdu_add_frame). It also does not seem to have any checks to
ensure that rate control probing frames are not aggregated.
- Felix
On 08/20/2013 06:56 AM, Felix Fietkau wrote:
> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>> <[email protected]> wrote:
>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>> Hi guys,
>>>>>
>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>> connecting to the network.
>>>>>
>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>> the top of the call trace reads:
>>>>>
>>>>> brcms_c_compute_rtscts_dur
>>>>> brcms_c_ampdu_finalize
>>>>> ampdu_finalize
>>>>> dma_txfast
>>>>> brcms_c_txfifo
>>>>> brcms_c_sendpkt_mac80211
>>>>> brcms_ops_tx
>>>>> __ieee80211_tx
>>>>>
>>>>> I bisected the problem and the first bad commit is
>>>>>
>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>> Author: Felix Fietkau <[email protected]>
>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>
>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>
>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>
>>>>> Reverting it on top of .7 fixes the problem.
>>>>>
>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>> that if it would help though.
>>>>>
>>>>> Let me know if you need any more information.
>>>>
>>>> Do you have this same problem with 3.11-rc6 as well?
>>>
>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>> commit on top of -rc6 fixes the problem.
>>
>> Great, thanks.
>>
>> Felix and Johannes, any chance we can get this reverted in Linus tree
>> soon, and push that revert back to the 3.10 stable tree as well?
> I'd like to avoid a revert, since that will simply replace one set of
> issues with another. Let's limit the use of the feature that brcmsmac
> can't handle to drivers that are known to work with it. Tom, Please
> test this patch to see if it fixes your issue.
Hi Felix,
I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck
support and only change brcmsmac.
Regards,
Arend
> - Felix
> ---
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24,
> IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25,
> IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27,
> };
>
> /**
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
> if (sband->band != IEEE80211_BAND_2GHZ)
> return;
>
> + if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
> + return;
> +
> mi->cck_supported = 0;
> mi->cck_supported_short = 0;
> for (i = 0; i < 4; i++) {
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_SPECTRUM_MGMT |
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> - IEEE80211_HW_SUPPORTS_RC_TABLE;
> + IEEE80211_HW_SUPPORTS_RC_TABLE |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
> IEEE80211_HW_SUPPORTS_RC_TABLE |
> - IEEE80211_HW_SIGNAL_DBM;
> + IEEE80211_HW_SIGNAL_DBM |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (!modparam_noht) {
> /*
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_AMPDU_AGGREGATION |
> - IEEE80211_HW_REPORTS_TX_ACK_STATUS;
> + IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> /*
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>> Hi guys,
>>
>> Starting with 3.10.6 (and still present in .7) I get an oops on
>> connecting to the network.
>>
>> The attached picture shows the oops. In case it does not reach the ML,
>> the top of the call trace reads:
>>
>> brcms_c_compute_rtscts_dur
>> brcms_c_ampdu_finalize
>> ampdu_finalize
>> dma_txfast
>> brcms_c_txfifo
>> brcms_c_sendpkt_mac80211
>> brcms_ops_tx
>> __ieee80211_tx
>>
>> I bisected the problem and the first bad commit is
>>
>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>> Author: Felix Fietkau <[email protected]>
>> Date: Fri Jun 28 21:04:35 2013 +0200
>>
>> mac80211/minstrel_ht: fix cck rate sampling
>>
>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>
>> Reverting it on top of .7 fixes the problem.
>>
>> I had the same (I suppose) problem on mainline some time ago, but I
>> have not bisected it, verified that the problem still occurs there, or
>> checked if reverting the upstream patch fixes it. I'd be happy to do
>> that if it would help though.
>>
>> Let me know if you need any more information.
>
> Do you have this same problem with 3.11-rc6 as well?
Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.
Cheers,
Tom
On 08/20/2013 07:36 PM, Felix Fietkau wrote:
> On 2013-08-20 10:15 AM, Arend van Spriel wrote:
>> Hi Felix,
>>
>> I have been diving into root causing why brcmsmac can not handle cck
>> fallback rates, because it should. Maybe it is better to flag no cck
>> support and only change brcmsmac.
> I prefer having a flag to enable it over one to disable it, because it
> fits better with the existing flags. Also, future drivers may not always
> be properly prepared to handle CCK in A-MPDU sessions either.
Ok. It just looked a bit strange that a problem in brcmsmac results in
changing other drivers.
> By the way, I took a short look at brcmsmac and found more issues that
> you should look into if you want to fix this.
>
> First of all, you should probably make sure that the hardware does not
> try to send an A-MPDU using a CCK rate (prepare it as a single frame in
> brcms_c_ampdu_add_frame). It also does not seem to have any checks to
> ensure that rate control probing frames are not aggregated.
Thanks, Felix. I also noticed that our proprietary driver has code in
place for these scenarios.
Gr. AvS
On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel <[email protected]> wrote:
> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
>>
>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>>>
>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>>>
>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>>> <[email protected]> wrote:
>>>>>
>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>>> connecting to the network.
>>>>>>
>>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>>> the top of the call trace reads:
>>>>>>
>>>>>> brcms_c_compute_rtscts_dur
>>>>>> brcms_c_ampdu_finalize
>>>>>> ampdu_finalize
>>>>>> dma_txfast
>>>>>> brcms_c_txfifo
>>>>>> brcms_c_sendpkt_mac80211
>>>>>> brcms_ops_tx
>>>>>> __ieee80211_tx
>>>>>>
>>>>>> I bisected the problem and the first bad commit is
>>>>>>
>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>>> Author: Felix Fietkau <[email protected]>
>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>>
>>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>>
>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>>
>>>>>> Reverting it on top of .7 fixes the problem.
>>>>>>
>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>>> that if it would help though.
>>>>>>
>>>>>> Let me know if you need any more information.
>>>>>
>>>>>
>>>>> Do you have this same problem with 3.11-rc6 as well?
>>>>
>>>>
>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>>> commit on top of -rc6 fixes the problem.
>>>
>>>
>>> Great, thanks.
>>>
>>> Felix and Johannes, any chance we can get this reverted in Linus tree
>>> soon, and push that revert back to the 3.10 stable tree as well?
>>
>> I'd like to avoid a revert, since that will simply replace one set of
>> issues with another. Let's limit the use of the feature that brcmsmac
>> can't handle to drivers that are known to work with it. Tom, Please
>> test this patch to see if it fixes your issue.
>
>
> Hi Felix,
>
> I have been diving into root causing why brcmsmac can not handle cck
> fallback rates, because it should. Maybe it is better to flag no cck support
> and only change brcmsmac.
Hi Arend,
In case you cannot reproduce, let me know if I can help with testing patches.
Cheers,
Tom
On 08/21/2013 02:11 AM, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 4:15 AM, Arend van Spriel <[email protected]> wrote:
>> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
>>>
>>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>>>>
>>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>>>>
>>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>>>> connecting to the network.
>>>>>>>
>>>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>>>> the top of the call trace reads:
>>>>>>>
>>>>>>> brcms_c_compute_rtscts_dur
>>>>>>> brcms_c_ampdu_finalize
>>>>>>> ampdu_finalize
>>>>>>> dma_txfast
>>>>>>> brcms_c_txfifo
>>>>>>> brcms_c_sendpkt_mac80211
>>>>>>> brcms_ops_tx
>>>>>>> __ieee80211_tx
>>>>>>>
>>>>>>> I bisected the problem and the first bad commit is
>>>>>>>
>>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>>>> Author: Felix Fietkau <[email protected]>
>>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>>>
>>>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>>>
>>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>>>
>>>>>>> Reverting it on top of .7 fixes the problem.
>>>>>>>
>>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>>>> that if it would help though.
>>>>>>>
>>>>>>> Let me know if you need any more information.
>>>>>>
>>>>>>
>>>>>> Do you have this same problem with 3.11-rc6 as well?
>>>>>
>>>>>
>>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>>>> commit on top of -rc6 fixes the problem.
>>>>
>>>>
>>>> Great, thanks.
>>>>
>>>> Felix and Johannes, any chance we can get this reverted in Linus tree
>>>> soon, and push that revert back to the 3.10 stable tree as well?
>>>
>>> I'd like to avoid a revert, since that will simply replace one set of
>>> issues with another. Let's limit the use of the feature that brcmsmac
>>> can't handle to drivers that are known to work with it. Tom, Please
>>> test this patch to see if it fixes your issue.
>>
>>
>> Hi Felix,
>>
>> I have been diving into root causing why brcmsmac can not handle cck
>> fallback rates, because it should. Maybe it is better to flag no cck support
>> and only change brcmsmac.
>
> We have a number of users hitting this in Fedora 18 and 19 now. We're
> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
> and I'm sure we can find people to test easily.
There is already another one (possibly) dealing with the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=989269
One of them should probably be flagged as duplicate.
> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
> kernel for people. If that's going to be some time coming, perhaps
> it's better to grab Felix's patch on a temporary basis?
I think it is better to grab Felix's patch because as we both observed
there is stuff missing in brcmsmac to deal with CCK rates and A-MPDU
packet aggregation.
Regards,
Arend
On Wed, Aug 21, 2013 at 10:27 AM, Arend van Spriel <[email protected]> wrote:
> On 08/21/13 14:38, Josh Boyer wrote:
>>
>> On Wed, Aug 21, 2013 at 4:52 AM, Arend van Spriel<[email protected]>
>> wrote:
>>>>>
>>>>> Hi Felix,
>>>>>
>>>>> I have been diving into root causing why brcmsmac can not handle cck
>>>>> fallback rates, because it should. Maybe it is better to flag no cck
>>>>> support
>>>>> and only change brcmsmac.
>>>>
>>>>
>>>>
>>>> We have a number of users hitting this in Fedora 18 and 19 now. We're
>>>> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
>>>> and I'm sure we can find people to test easily.
>>>
>>>
>>>
>>> There is already another one (possibly) dealing with the same issue:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=989269
>>>
>>> One of them should probably be flagged as duplicate.
>>>
>>>
>>>> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
>>>> kernel for people. If that's going to be some time coming, perhaps
>>>> it's better to grab Felix's patch on a temporary basis?
>>>
>>>
>>>
>>> I think it is better to grab Felix's patch because as we both observed
>>> there
>>> is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
>>> aggregation.
>>
>>
>> OK, thanks.
>>
>> Felix, are you going to send that upstream?
>
>
> It already has been sent:
> http://mid.gmane.org/[email protected]
>
> Johannes has submitted it to John so it is getting there soon(ish).
Ah, wonderful. Thanks!
josh
On Tue, Aug 20, 2013 at 4:15 AM, Arend van Spriel <[email protected]> wrote:
> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
>>
>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>>>
>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>>>
>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>>> <[email protected]> wrote:
>>>>>
>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>>> connecting to the network.
>>>>>>
>>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>>> the top of the call trace reads:
>>>>>>
>>>>>> brcms_c_compute_rtscts_dur
>>>>>> brcms_c_ampdu_finalize
>>>>>> ampdu_finalize
>>>>>> dma_txfast
>>>>>> brcms_c_txfifo
>>>>>> brcms_c_sendpkt_mac80211
>>>>>> brcms_ops_tx
>>>>>> __ieee80211_tx
>>>>>>
>>>>>> I bisected the problem and the first bad commit is
>>>>>>
>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>>> Author: Felix Fietkau <[email protected]>
>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>>
>>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>>
>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>>
>>>>>> Reverting it on top of .7 fixes the problem.
>>>>>>
>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>>> that if it would help though.
>>>>>>
>>>>>> Let me know if you need any more information.
>>>>>
>>>>>
>>>>> Do you have this same problem with 3.11-rc6 as well?
>>>>
>>>>
>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>>> commit on top of -rc6 fixes the problem.
>>>
>>>
>>> Great, thanks.
>>>
>>> Felix and Johannes, any chance we can get this reverted in Linus tree
>>> soon, and push that revert back to the 3.10 stable tree as well?
>>
>> I'd like to avoid a revert, since that will simply replace one set of
>> issues with another. Let's limit the use of the feature that brcmsmac
>> can't handle to drivers that are known to work with it. Tom, Please
>> test this patch to see if it fixes your issue.
>
>
> Hi Felix,
>
> I have been diving into root causing why brcmsmac can not handle cck
> fallback rates, because it should. Maybe it is better to flag no cck support
> and only change brcmsmac.
We have a number of users hitting this in Fedora 18 and 19 now. We're
tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
and I'm sure we can find people to test easily.
If you have a patch disabling cck in brcmsmac, I'd be happy to build a
kernel for people. If that's going to be some time coming, perhaps
it's better to grab Felix's patch on a temporary basis?
josh
On 08/20/2013 10:36 AM, Tom Gundersen wrote:
> On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel <[email protected]> wrote:
>> On 08/20/2013 06:56 AM, Felix Fietkau wrote:
>>>
>>> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>>>>
>>>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>>>>
>>>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> Starting with 3.10.6 (and still present in .7) I get an oops on
>>>>>>> connecting to the network.
>>>>>>>
>>>>>>> The attached picture shows the oops. In case it does not reach the ML,
>>>>>>> the top of the call trace reads:
>>>>>>>
>>>>>>> brcms_c_compute_rtscts_dur
>>>>>>> brcms_c_ampdu_finalize
>>>>>>> ampdu_finalize
>>>>>>> dma_txfast
>>>>>>> brcms_c_txfifo
>>>>>>> brcms_c_sendpkt_mac80211
>>>>>>> brcms_ops_tx
>>>>>>> __ieee80211_tx
>>>>>>>
>>>>>>> I bisected the problem and the first bad commit is
>>>>>>>
>>>>>>> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>>>>>> Author: Felix Fietkau <[email protected]>
>>>>>>> Date: Fri Jun 28 21:04:35 2013 +0200
>>>>>>>
>>>>>>> mac80211/minstrel_ht: fix cck rate sampling
>>>>>>>
>>>>>>> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>>>>>>
>>>>>>> Reverting it on top of .7 fixes the problem.
>>>>>>>
>>>>>>> I had the same (I suppose) problem on mainline some time ago, but I
>>>>>>> have not bisected it, verified that the problem still occurs there, or
>>>>>>> checked if reverting the upstream patch fixes it. I'd be happy to do
>>>>>>> that if it would help though.
>>>>>>>
>>>>>>> Let me know if you need any more information.
>>>>>>
>>>>>>
>>>>>> Do you have this same problem with 3.11-rc6 as well?
>>>>>
>>>>>
>>>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>>>> commit on top of -rc6 fixes the problem.
>>>>
>>>>
>>>> Great, thanks.
>>>>
>>>> Felix and Johannes, any chance we can get this reverted in Linus tree
>>>> soon, and push that revert back to the 3.10 stable tree as well?
>>>
>>> I'd like to avoid a revert, since that will simply replace one set of
>>> issues with another. Let's limit the use of the feature that brcmsmac
>>> can't handle to drivers that are known to work with it. Tom, Please
>>> test this patch to see if it fixes your issue.
>>
>>
>> Hi Felix,
>>
>> I have been diving into root causing why brcmsmac can not handle cck
>> fallback rates, because it should. Maybe it is better to flag no cck support
>> and only change brcmsmac.
>
> Hi Arend,
>
> In case you cannot reproduce, let me know if I can help with testing patches.
So far I have not been able to reproduce it. I have a patch to avoid the
oops, but the transmit of the related frames will fail in the device so
it is not a real fix. I will let you you know.
Regards,
Arend
> Cheers,
>
> Tom
>
On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
> >> Hi guys,
> >>
> >> Starting with 3.10.6 (and still present in .7) I get an oops on
> >> connecting to the network.
> >>
> >> The attached picture shows the oops. In case it does not reach the ML,
> >> the top of the call trace reads:
> >>
> >> brcms_c_compute_rtscts_dur
> >> brcms_c_ampdu_finalize
> >> ampdu_finalize
> >> dma_txfast
> >> brcms_c_txfifo
> >> brcms_c_sendpkt_mac80211
> >> brcms_ops_tx
> >> __ieee80211_tx
> >>
> >> I bisected the problem and the first bad commit is
> >>
> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
> >> Author: Felix Fietkau <[email protected]>
> >> Date: Fri Jun 28 21:04:35 2013 +0200
> >>
> >> mac80211/minstrel_ht: fix cck rate sampling
> >>
> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
> >>
> >> Reverting it on top of .7 fixes the problem.
> >>
> >> I had the same (I suppose) problem on mainline some time ago, but I
> >> have not bisected it, verified that the problem still occurs there, or
> >> checked if reverting the upstream patch fixes it. I'd be happy to do
> >> that if it would help though.
> >>
> >> Let me know if you need any more information.
> >
> > Do you have this same problem with 3.11-rc6 as well?
>
> Yes, I just confirmed. I also confirmed that reverting the mainline
> commit on top of -rc6 fixes the problem.
Great, thanks.
Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?
thanks,
greg k-h
On 08/21/13 14:38, Josh Boyer wrote:
> On Wed, Aug 21, 2013 at 4:52 AM, Arend van Spriel<[email protected]> wrote:
>>>> Hi Felix,
>>>>
>>>> I have been diving into root causing why brcmsmac can not handle cck
>>>> fallback rates, because it should. Maybe it is better to flag no cck
>>>> support
>>>> and only change brcmsmac.
>>>
>>>
>>> We have a number of users hitting this in Fedora 18 and 19 now. We're
>>> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
>>> and I'm sure we can find people to test easily.
>>
>>
>> There is already another one (possibly) dealing with the same issue:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=989269
>>
>> One of them should probably be flagged as duplicate.
>>
>>
>>> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
>>> kernel for people. If that's going to be some time coming, perhaps
>>> it's better to grab Felix's patch on a temporary basis?
>>
>>
>> I think it is better to grab Felix's patch because as we both observed there
>> is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
>> aggregation.
>
> OK, thanks.
>
> Felix, are you going to send that upstream?
It already has been sent:
http://mid.gmane.org/[email protected]
Johannes has submitted it to John so it is getting there soon(ish).
> josh
Regards,
Arend
On Wed, Aug 21, 2013 at 4:52 AM, Arend van Spriel <[email protected]> wrote:
>>> Hi Felix,
>>>
>>> I have been diving into root causing why brcmsmac can not handle cck
>>> fallback rates, because it should. Maybe it is better to flag no cck
>>> support
>>> and only change brcmsmac.
>>
>>
>> We have a number of users hitting this in Fedora 18 and 19 now. We're
>> tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
>> and I'm sure we can find people to test easily.
>
>
> There is already another one (possibly) dealing with the same issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=989269
>
> One of them should probably be flagged as duplicate.
>
>
>> If you have a patch disabling cck in brcmsmac, I'd be happy to build a
>> kernel for people. If that's going to be some time coming, perhaps
>> it's better to grab Felix's patch on a temporary basis?
>
>
> I think it is better to grab Felix's patch because as we both observed there
> is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
> aggregation.
OK, thanks.
Felix, are you going to send that upstream?
josh