LinuxLists.cc - 2.6.25-rc2 regression in rt61pci wireless driver

Attachments:

(No filename) (2.68 kB)
debugfsdump-2.6.24.2 (6.59 kB)
debugfsdump-2.6.25-rc2-after (6.59 kB)
debugfsdump-2.6.25-rc2-before (6.59 kB)
Download all attachments

2008-02-18 18:16:30

by Ivo Van Doorn

[permalink] [raw]

Subject: Re: 2.6.25-rc2 regression in rt61pci wireless driver

Almost forgot:

> > In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
> > of network activity. The following screen cut shows what I typically
> > see:
>
> How complete is this failure? Just TX or also RX?
>
> Could you use the tools found here:
> http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
>
> and capture all TX/RX frames going through the hardware?
> Note that after the failure, this dumping facitilty should still report
> any ping request you might send to the interface.

Note that this feature is only present in 2.6.25.

> I have a series of tests I would like to request from you,
> you mentioned you already enabled debugfs, and that is just what we need. ;)
> Please use attached script to create dumps of the hardware register contents.

The debugfs register files were moved into a seperate folder somewhere between
2.6.24 and 2.6.25. This means you might have to edit the file slightly to make it
point to the correct location of the chipset file.

Ivo

2008-02-19 19:01:06

On Thursday 21 February 2008, Ivo van Doorn wrote:
> On Thursday 21 February 2008, Chris Vine wrote:
> > On Wed, 2008-02-20 at 21:16 +0000, Chris Vine wrote:
> > > On Wed, 2008-02-20 at 21:50 +0100, Ivo van Doorn wrote:
> > > [snip]
> > > > On Wednesday 20 February 2008, Chris Vine wrote:
> > > > > I did that yesterday and it just reported a kernel panic on the terminal
> > > > > with the message:
> > > > >
> > > > > Kernel panic - not syncing: Aiee, killing interrupt handler!
> > > >
> > > > I have an idea, could you try below patch?
> > > > Note that while applying it will mention something about a line offset, but that can be ignored.
> > > >
> > > > This could perhaps also fix the TX/RX issue mentioned earlier in the thread, but I am not
> > > > quite sure about that.
> > >
> > > The patch applied OK (with some offsets as you say) but it doesn't help.
> > > The kernel panic still occurs when association is attempted.
> >
> > Here's some further information.
> >
> > I have a fully functioning version of rt2x00-2.0.14 and mac80211 from
> > wireless-2.6/compat-wireless-2.6 of mid January which works fine on
> > kernel 2.6.24. On doing a comparison with the rt2x00 in vanilla kernel
> > 2.6.25-rc2, there are no material differences. (There was a slight
> > change in the declaration a variable in rt2x00usb.c but it is
> > immaterial.)
> >
> > I compiled up the working mid-January version of rt2x00 and mac80211
> > under kernel 2.6.25-rc2 and I get exactly the same result as I reported
> > earlier, namely I get a kernel panic as soon as I try to associate. It
> > looks therefore as if something has changed within the remainder of the
> > kernel which has caused rt2x00 (and possibly mac80211?) to break.
> >
> > This probably explains the problem another user reported with rt61.
>
> Perhaps something similar like:
> http://bugzilla.kernel.org/show_bug.cgi?id=10058
> in there a reference is made to the following patch:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/broken-out/revert-send-a-single-notification-on-device-state-changes.patch
>
> Does applying that help?

I'm afraid not, Ivo. The test I ran last night was against 2.6.25.-rc2-git4 and
that already has this patch applied. Furthermore, I have another card that uses
the rtl8180 driver and that works reliably. I, therefore, suspect that my problem
lies within the rt61pci driver or the rt2x00 infrastructure.

Chris
>
> Ivo
>

--
Beauty is in the eye of the beerholder.

2008-02-20 22:14:31

On Wed, 27 Feb 2008 12:25:46 -0500
"John W. Linville" <[email protected]> wrote:

> That might be easier said than done. It looks like that patch depends
> on the big cfg80211 API change queued for 2.6.26.
>
> Stefano offered to rebase that on 2.6.25. Stefano, could you post
> that as part of this thread?

Sorry for the delay. This is based on 2.6.25-rc3. Please test.

---

Merge rate_control_pid_shift_adjust() to rate_control_pid_adjust_rate()
in order to make the learning algorithm aware of constraints on rates. Also
add some comments and rename variables.

This fixes a bug which prevented 802.11b/g non-AP STAs from working with
802.11b only AP STAs.

Signed-off-by: Stefano Brivio <[email protected]>
---
Index: linux-2.6.24/net/mac80211/rc80211_pid_algo.c
===================================================================
--- linux-2.6.24.orig/net/mac80211/rc80211_pid_algo.c
+++ linux-2.6.24/net/mac80211/rc80211_pid_algo.c
@@ -2,7 +2,7 @@
* Copyright 2002-2005, Instant802 Networks, Inc.
* Copyright 2005, Devicescape Software, Inc.
* Copyright 2007, Mattias Nissler <[email protected]>
- * Copyright 2007, Stefano Brivio <[email protected]>
+ * Copyright 2007-2008, Stefano Brivio <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -63,72 +63,66 @@
* RC_PID_ARITH_SHIFT.
*/

-
-/* Shift the adjustment so that we won't switch to a lower rate if it exhibited
- * a worse failed frames behaviour and we'll choose the highest rate whose
- * failed frames behaviour is not worse than the one of the original rate
- * target. While at it, check that the adjustment is within the ranges. Then,
- * provide the new rate index. */
-static int rate_control_pid_shift_adjust(struct rc_pid_rateinfo *r,
- int adj, int cur, int l)
-{
- int i, j, k, tmp;
-
- j = r[cur].rev_index;
- i = j + adj;
-
- if (i < 0)
- return r[0].index;
- if (i >= l - 1)
- return r[l - 1].index;
-
- tmp = i;
-
- if (adj < 0) {
- for (k = j; k >= i; k--)
- if (r[k].diff <= r[j].diff)
- tmp = k;
- } else {
- for (k = i + 1; k + i < l; k++)
- if (r[k].diff <= r[i].diff)
- tmp = k;
- }
-
- return r[tmp].index;
-}
-
+/* Adjust the rate while ensuring that we won't switch to a lower rate if it
+ * exhibited a worse failed frames behaviour and we'll choose the highest rate
+ * whose failed frames behaviour is not worse than the one of the original rate
+ * target. While at it, check that the new rate is valid. */
static void rate_control_pid_adjust_rate(struct ieee80211_local *local,
struct sta_info *sta, int adj,
struct rc_pid_rateinfo *rinfo)
{
struct ieee80211_sub_if_data *sdata;
struct ieee80211_hw_mode *mode;
- int newidx;
- int maxrate;
- int back = (adj > 0) ? 1 : -1;
+ int cur_sorted, new_sorted, probe, tmp, n_bitrates;
+ int cur = sta->txrate;

sdata = IEEE80211_DEV_TO_SUB_IF(sta->dev);

mode = local->oper_hw_mode;
- maxrate = sdata->bss ? sdata->bss->max_ratectrl_rateidx : -1;
+ n_bitrates = mode->num_rates;

- newidx = rate_control_pid_shift_adjust(rinfo, adj, sta->txrate,
- mode->num_rates);
+ /* Map passed arguments to sorted values. */
+ cur_sorted = rinfo[cur].rev_index;
+ new_sorted = cur_sorted + adj;
+
+ /* Check limits. */
+ if (new_sorted < 0)
+ new_sorted = rinfo[0].rev_index;
+ else if (new_sorted >= n_bitrates)
+ new_sorted = rinfo[n_bitrates - 1].rev_index;

- while (newidx != sta->txrate) {
- if (rate_supported(sta, mode, newidx) &&
- (maxrate < 0 || newidx <= maxrate)) {
- sta->txrate = newidx;
- break;
- }
+ tmp = new_sorted;

- newidx += back;
+ if (adj < 0) {
+ /* Ensure that the rate decrease isn't disadvantageous. */
+ for (probe = cur_sorted; probe >= new_sorted; probe--)
+ if (rinfo[probe].diff <= rinfo[cur_sorted].diff &&
+ rate_supported(sta, mode, rinfo[probe].index))
+ tmp = probe;
+ } else {
+ /* Look for rate increase with zero (or below) cost. */
+ for (probe = new_sorted + 1; probe < n_bitrates; probe++)
+ if (rinfo[probe].diff <= rinfo[new_sorted].diff &&
+ rate_supported(sta, mode, rinfo[probe].index))
+ tmp = probe;
}

+ /* Fit the rate found to the nearest supported rate. */
+ do {
+ if (rate_supported(sta, mode, rinfo[tmp].index)) {
+ sta->txrate = rinfo[tmp].index;
+ break;
+ }
+ if (adj < 0)
+ tmp--;
+ else
+ tmp++;
+ } while (tmp < n_bitrates && tmp >= 0);
+
#ifdef CONFIG_MAC80211_DEBUGFS
rate_control_pid_event_rate_change(
&((struct rc_pid_sta_info *)sta->rate_ctrl_priv)->events,
- newidx, mode->rates[newidx].rate);
+ cur, mode->rates[cur].rate);
#endif
}

--
Ciao
Stefano