Hi Ivo,

On 18/02/2008, Ivo van Doorn wrote:
> Hi,
>

[...]

> Above traces should be enough, but to determine where rt2x00 broke
> down approximatly I need to have a few test result on specific moments.
> Could you test the kernel with the following versions:
>
> rt2x00 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> rt2x00 2.0.12 a3c7aa58df7df80aa05f166fe3e42482247164cf
> rt2x00 2.0.13 5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
>
> Checking those out is simply a matter of:
> git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> git checkout 2.0.11
>

OK, we seem to be struggling a little, so I've built an installed git
and cloned Linus' 2.6 tree. My wireless network dies after a few pings
with rt2x00 2.0.11.

> No further bisecting is needed, but with above tests I can at least
> narrow it down to find the cause of this issue.
>

If you need me to bisect, just shout. Please be patient though, I'm
exploring new territory here :-)

Thanks

Chris
> Thanks.
>
>
> Ivo
>
>


--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Friday 22 February 2008, Chris Clayton wrote:
> On Thursday 21 February 2008, Chris Vine wrote:
> > On Thu, 2008-02-21 at 23:04 +0000, Chris Clayton wrote:
> > > On Thursday 21 February 2008, Ivo van Doorn wrote:
> > > > On Thursday 21 February 2008, Chris Vine wrote:
> > [snip]
> > > > > 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/kerne...-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.
> >
> > Does the same happen with 2.0.14 under kernel 2.6.24?
>
> Unfortunately, a 2.6.24.2 tree with the drivers/net/wireless/rt2x00 directory replaced with that from 2.6.25-rc2-git4 doesn't build:

You need the mac80211 compat module from Intel. That allows new mac80211 versions to run
on older kernels. When you use that you need to grab the rt2x00 cvs tarball from:
http://rt2x00.serialmonkey.com/wiki/index.php/Downloads

which allows rt2x00 to be compiled outside of the kernel.

> In file included from drivers/net/wireless/rt2x00/rt2x00dev.c:29:
> drivers/net/wireless/rt2x00/rt2x00.h:942: warning: `struct ieee80211_bss_conf' declared inside parameter list
> drivers/net/wireless/rt2x00/rt2x00.h:942: warning: its scope is only this definition or declaration, which is probably not what you want
>
> [...]
>
> drivers/net/wireless/rt2x00/rt2x00dev.c: In function `rt2x00lib_configuration_scheduled':
> drivers/net/wireless/rt2x00/rt2x00dev.c:484: error: storage size of `bss_conf' isn't known
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: `BSS_CHANGED_ERP_PREAMBLE' undeclared (first use in this function)
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: (Each undeclared identifier is reported only once
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: for each function it appears in.)
> drivers/net/wireless/rt2x00/rt2x00dev.c:484: warning: unused variable `bss_conf'
> drivers/net/wireless/rt2x00/rt2x00dev.c: In function `rt2x00lib_beacondone_scheduled':
> drivers/net/wireless/rt2x00/rt2x00dev.c:511: warning: passing arg 2 of `ieee80211_beacon_get' makes integer from pointer without a cast

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Friday 22 February 2008, Chris Clayton wrote:
> Hi Ivo,
>
> On 18/02/2008, Ivo van Doorn wrote:
> > Hi,
> >
>
> [...]
>
> > Above traces should be enough, but to determine where rt2x00 broke
> > down approximatly I need to have a few test result on specific moments.
> > Could you test the kernel with the following versions:
> >
> > rt2x00 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> > rt2x00 2.0.12 a3c7aa58df7df80aa05f166fe3e42482247164cf
> > rt2x00 2.0.13 5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
> >
> > Checking those out is simply a matter of:
> > git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> > git checkout 2.0.11
> >
>
> OK, we seem to be struggling a little, so I've built an installed git
> and cloned Linus' 2.6 tree. My wireless network dies after a few pings
> with rt2x00 2.0.11.
>
> > No further bisecting is needed, but with above tests I can at least
> > narrow it down to find the cause of this issue.
> >
>
> If you need me to bisect, just shout. Please be patient though, I'm
> exploring new territory here :-)

I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
introduced software diversity. And that is already something I suspect
of being broken.

Unfortunately software diversity was a bugfix and fix in one,
the previous setup was broken for some hardware since the
lack of software diversity caused problems.

Could you check if below patch helps in any way?

Ivo

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index a1d8e33..6995912 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -122,6 +122,10 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
libconf.ant.rx = rx;
libconf.ant.tx = tx;

+ if (rx == rt2x00dev->link.ant.active.rx &&
+ tx == rt2x00dev->link.ant.active.tx)
+ return;
+
/*
* Antenna setup changes require the RX to be disabled,
* else the changes will be ignored by the device.
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 65a512f..4325c08 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -191,16 +191,16 @@ static void rt2x00lib_evaluate_antenna_sample(struct rt2x00_dev *rt2x00dev)
return;

if (rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) {
- if (sample_a > sample_b && rx == ANTENNA_B)
+ if (sample_a > sample_b)
rx = ANTENNA_A;
- else if (rx == ANTENNA_A)
+ else
rx = ANTENNA_B;
}

if (rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY) {
- if (sample_a > sample_b && tx == ANTENNA_B)
+ if (sample_a > sample_b)
tx = ANTENNA_A;
- else if (tx == ANTENNA_A)
+ else
tx = ANTENNA_B;
}

@@ -257,7 +257,7 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev)

if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) &&
!(rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY)) {
- rt2x00dev->link.ant.flags &= ~ANTENNA_MODE_SAMPLE;
+ rt2x00dev->link.ant.flags = 0;
return;
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 2008-02-22 at 07:39 +0000, Chris Clayton wrote:
> On Thursday 21 February 2008, Chris Vine wrote:
[snip]
> >
> > Does the same happen with 2.0.14 under kernel 2.6.24?
>
> Unfortunately, a 2.6.24.2 tree with the drivers/net/wireless/rt2x00 directory replaced with that from 2.6.25-rc2-git4 doesn't build:

You have to have a version of mac80211 which is current with the version
of rt2x00 2.0.14. If you don't want to go back into wireless-2.6 git to
do that I can send you my known working copy (for rt73 and I hope for
rt61) of compat-wireless-2.6 which will compile under 2.6.24. However
it is just over 1MB in size so I won't sent it to you unless you would
like me to do that instead of you pulling git from wireless-2.6 for mid
January (actually the most recent working version would be immediately
before the patch which raised the version of rt2x00 to 2.1.0).

Chris


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

Firstly apologies for trimming linux-kernel and linux-wireless from my reply
to Ivo yesterday. Basically, I replied saying that the patch below didn't fix
the problem. But please do read on...

On Friday 22 February 2008, Ivo van Doorn wrote:
> On Friday 22 February 2008, Chris Clayton wrote:
> > Hi Ivo,
> >
> > On 18/02/2008, Ivo van Doorn wrote:
> > > Hi,
> >
> > [...]
> >
> > > Above traces should be enough, but to determine where rt2x00 broke
> > > down approximatly I need to have a few test result on specific
> > > moments. Could you test the kernel with the following versions:
> > >
> > > rt2x00 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> > > rt2x00 2.0.12 a3c7aa58df7df80aa05f166fe3e42482247164cf
> > > rt2x00 2.0.13 5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
> > >
> > > Checking those out is simply a matter of:
> > > git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> > > git checkout 2.0.11
> >
> > OK, we seem to be struggling a little, so I've built an installed git
> > and cloned Linus' 2.6 tree. My wireless network dies after a few pings
> > with rt2x00 2.0.11.
> >
> > > No further bisecting is needed, but with above tests I can at least
> > > narrow it down to find the cause of this issue.
> >
> > If you need me to bisect, just shout. Please be patient though, I'm
> > exploring new territory here :-)
>
> I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
> introduced software diversity. And that is already something I suspect
> of being broken.
>
I've bisected anyway and although the results are not absolutely conclusive,
as I neared the end of the process, I was amongst a bunch of mac80211
patches. This set me on a path that resulted in me discovering that with the
rt61pci driver, I can freeze my wireless network connection almost at will if
I set mac82011's ieee80211_default_rc_algo parameter to 'pid'. if the
parametre is set to 'simple', the network seems to be reliable. I've just let
the ping application run on and ping another box on my network almost 1500
times whilst repeatedly transferring a kernel source tarball by ftp from
another box and the network connection was mantained That's with the
parameter set to 'simple', if \I set it to 'pid' the connection rarely
survives more than 40 pings even without the ftp activity.

If I replace my wireless card with one that uses the rtl8180 driver, the
network connection seems to be reliable regardless of how I set the
parameter, although I admit that i have not tested this extensively yet. I'll
do that now and report later.

Hope this helps.

Chris

> Unfortunately software diversity was a bugfix and fix in one,
> the previous setup was broken for some hardware since the
> lack of software diversity caused problems.
>
> Could you check if below patch helps in any way?
>
> Ivo
>
> ---
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c
> b/drivers/net/wireless/rt2x00/rt2x00config.c index a1d8e33..6995912 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00config.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00config.c
> @@ -122,6 +122,10 @@ void rt2x00lib_config_antenna(struct rt2x00_dev
> *rt2x00dev, libconf.ant.rx = rx;
> libconf.ant.tx = tx;
>
> + if (rx == rt2x00dev->link.ant.active.rx &&
> + tx == rt2x00dev->link.ant.active.tx)
> + return;
> +
> /*
> * Antenna setup changes require the RX to be disabled,
> * else the changes will be ignored by the device.
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c
> b/drivers/net/wireless/rt2x00/rt2x00dev.c index 65a512f..4325c08 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -191,16 +191,16 @@ static void rt2x00lib_evaluate_antenna_sample(struct
> rt2x00_dev *rt2x00dev) return;
>
> if (rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) {
> - if (sample_a > sample_b && rx == ANTENNA_B)
> + if (sample_a > sample_b)
> rx = ANTENNA_A;
> - else if (rx == ANTENNA_A)
> + else
> rx = ANTENNA_B;
> }
>
> if (rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY) {
> - if (sample_a > sample_b && tx == ANTENNA_B)
> + if (sample_a > sample_b)
> tx = ANTENNA_A;
> - else if (tx == ANTENNA_A)
> + else
> tx = ANTENNA_B;
> }
>
> @@ -257,7 +257,7 @@ static void rt2x00lib_evaluate_antenna(struct
> rt2x00_dev *rt2x00dev)
>
> if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) &&
> !(rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY)) {
> - rt2x00dev->link.ant.flags &= ~ANTENNA_MODE_SAMPLE;
> + rt2x00dev->link.ant.flags = 0;
> return;
> }



--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

> > > > Checking those out is simply a matter of:
> > > > git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> > > > git checkout 2.0.11
> > >
> > > OK, we seem to be struggling a little, so I've built an installed git
> > > and cloned Linus' 2.6 tree. My wireless network dies after a few pings
> > > with rt2x00 2.0.11.
> > >
> > > > No further bisecting is needed, but with above tests I can at least
> > > > narrow it down to find the cause of this issue.
> > >
> > > If you need me to bisect, just shout. Please be patient though, I'm
> > > exploring new territory here :-)
> >
> > I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
> > introduced software diversity. And that is already something I suspect
> > of being broken.
> >
> I've bisected anyway and although the results are not absolutely conclusive,
> as I neared the end of the process, I was amongst a bunch of mac80211
> patches. This set me on a path that resulted in me discovering that with the
> rt61pci driver, I can freeze my wireless network connection almost at will if
> I set mac82011's ieee80211_default_rc_algo parameter to 'pid'. if the
> parametre is set to 'simple', the network seems to be reliable. I've just let
> the ping application run on and ping another box on my network almost 1500
> times whilst repeatedly transferring a kernel source tarball by ftp from
> another box and the network connection was mantained That's with the
> parameter set to 'simple', if \I set it to 'pid' the connection rarely
> survives more than 40 pings even without the ftp activity.
>
> If I replace my wireless card with one that uses the rtl8180 driver, the
> network connection seems to be reliable regardless of how I set the
> parameter, although I admit that i have not tested this extensively yet. I'll
> do that now and report later.

I'm about to send 4 patches to this (linux-wireless) list with patches
for rt2x00,
most of them you already tested individually, but several people reported
success after those patches.

Hopefully it will be working for you as well.

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

> > I've bisected anyway and although the results are not absolutely
> > conclusive, as I neared the end of the process, I was amongst a bunch of
> > mac80211 patches. This set me on a path that resulted in me discovering
> > that with the rt61pci driver, I can freeze my wireless network connection
> > almost at will if I set mac82011's ieee80211_default_rc_algo parameter to
> > 'pid'. if the parametre is set to 'simple', the network seems to be
> > reliable. I've just let the ping application run on and ping another box
> > on my network almost 1500 times whilst repeatedly transferring a kernel
> > source tarball by ftp from another box and the network connection was
> > mantained That's with the parameter set to 'simple', if \I set it to
> > 'pid' the connection rarely survives more than 40 pings even without the
> > ftp activity.
> >
> > If I replace my wireless card with one that uses the rtl8180 driver, the
> > network connection seems to be reliable regardless of how I set the
> > parameter, although I admit that i have not tested this extensively yet.
> > I'll do that now and report later.
>

I've rerun my tests with the rtl8180 driver and found the network to be
reliable with the mac82011 module's ieee80211_default_rc_algo parameter set
to either 'simple' or 'pid'.

> I'm about to send 4 patches to this (linux-wireless) list with patches
> for rt2x00,
> most of them you already tested individually, but several people reported
> success after those patches.
>
> Hopefully it will be working for you as well.
>

Sorry, but that's not the case. I find the same results as without the
patches. With the parameter set to 'pid', the network connection fails very
quickly, but with it set to 'simple' I can ping and ftp files to and from my
laptop as much as I like and the connection stays up. In fact, if anything
the patches seem to have made the network even more fragile, in that it fails
almost instantly once I start some network activity ( < 10 pings).

I'm sure this is not the hardware - it works perfectly with Windows XP, with
2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the
in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's
ieee80211_default_rc_algo parameter set to 'simple'.

Like I say above, sorry!

Chris

> Ivo

--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Feb 26, 2008 at 07:11:39PM +0000, Chris Clayton wrote:

> Sorry, but that's not the case. I find the same results as without the
> patches. With the parameter set to 'pid', the network connection fails very
> quickly, but with it set to 'simple' I can ping and ftp files to and from my
> laptop as much as I like and the connection stays up. In fact, if anything
> the patches seem to have made the network even more fragile, in that it fails
> almost instantly once I start some network activity ( < 10 pings).
>
> I'm sure this is not the hardware - it works perfectly with Windows XP, with
> 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the
> in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's
> ieee80211_default_rc_algo parameter set to 'simple'.

At last! Vindication for insisting that we keep 'simple' around!
Bwahahaha! :-)

So, am I to understand that 'pid' works find for you with rtl8180?
If so, then I wonder if Stefano and Ivo can help us figure-out
what kind of problem is sensitive to both driver _and_ rate control
algorithm?

Thanks,

John
--
John W. Linville
linville@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> > Sorry, but that's not the case. I find the same results as without the
> > patches. With the parameter set to 'pid', the network connection fails very
> > quickly, but with it set to 'simple' I can ping and ftp files to and from my
> > laptop as much as I like and the connection stays up. In fact, if anything
> > the patches seem to have made the network even more fragile, in that it fails
> > almost instantly once I start some network activity ( < 10 pings).
> >
> > I'm sure this is not the hardware - it works perfectly with Windows XP, with
> > 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the
> > in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's
> > ieee80211_default_rc_algo parameter set to 'simple'.
>
> At last! Vindication for insisting that we keep 'simple' around!
> Bwahahaha! :-)
>
> So, am I to understand that 'pid' works find for you with rtl8180?
> If so, then I wonder if Stefano and Ivo can help us figure-out
> what kind of problem is sensitive to both driver _and_ rate control
> algorithm?

rt2x00 is known to be less sensitive then the legacy drivers, scanning
produces less and more inconsistent results (Not all AP's are reported,
even when that AP has a high rssi), and the reported RSSI is often
much lower then expected with the distance to the AP.
I have compared many register dumps, but have never managed to
find a real register setting that might cause this. So what might be
the problem is that rt2x00 is not reporting the RSSI correctly to mac80211.

With the big difference between how mac80211 handles TX rates and
how the legacy drivers handle them, it is hard to make a comparison
where exactly things are going wrong. But in the end, I think it all
comes down to rt2x00 reporting invalid RSSI values to mac80211,
and/or the rate control mechanism being too dependent on some
statistics which are not provided by the driver.

I have to admit that I haven't looked into the 'pid' algorithm closely,
but could it be that some fields in the tx status report upon txdone
are being treated as "very important" while the driver doesn't report it
(For example ack signal strength)?

Other then that I have to say that rt2x00 never has reached a particular
state where link quality issues can be traced back to mac80211 or
the rate control mechanism. It usually was caused by a bug in the driver
itself. (rt2x00 cannot be considered stable yet for a very good reason. )

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 26/02/2008, John W. Linville wrote:
> On Tue, Feb 26, 2008 at 07:11:39PM +0000, Chris Clayton wrote:
>
> > Sorry, but that's not the case. I find the same results as without the
> > patches. With the parameter set to 'pid', the network connection fails very
> > quickly, but with it set to 'simple' I can ping and ftp files to and from my
> > laptop as much as I like and the connection stays up. In fact, if anything
> > the patches seem to have made the network even more fragile, in that it fails
> > almost instantly once I start some network activity ( < 10 pings).
> >
> > I'm sure this is not the hardware - it works perfectly with Windows XP, with
> > 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the
> > in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's
> > ieee80211_default_rc_algo parameter set to 'simple'.
>
>
> At last! Vindication for insisting that we keep 'simple' around!
> Bwahahaha! :-)
>

It's nice to be able to make someone happy :-)

> So, am I to understand that 'pid' works find for you with rtl8180?

Yes John, using the rtl8180 driver I get reliable network performance
with either 'pid' or 'simple'. With the rt61pci driver, I find that
'simple' provides a reliable network, but 'pid' simply does not work.
So keeping 'simple' around gets my vote too.

> If so, then I wonder if Stefano and Ivo can help us figure-out
> what kind of problem is sensitive to both driver _and_ rate control
> algorithm?
>

And I will help in any way I can, providing diagnostics and trying patches.

> Thanks,
>
> John
>
> --
> John W. Linville
> linville@tuxdriver.com
>

--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 26 Feb 2008 21:30:38 +0100
"Ivo Van Doorn" wrote:

> rt2x00 is known to be less sensitive then the legacy drivers, scanning
> produces less and more inconsistent results (Not all AP's are reported,
> even when that AP has a high rssi), and the reported RSSI is often
> much lower then expected with the distance to the AP.
> I have compared many register dumps, but have never managed to
> find a real register setting that might cause this. So what might be
> the problem is that rt2x00 is not reporting the RSSI correctly to mac80211.

No, we don't care at all about RSSI in rc80211-pid.

> I have to admit that I haven't looked into the 'pid' algorithm closely,
> but could it be that some fields in the tx status report upon txdone
> are being treated as "very important" while the driver doesn't report it
> (For example ack signal strength)?

The only important thing drivers should report back to mac80211 are ACKed
frames. In rc80211-pid (and it's just the same in rc80211-simple) the only
inputs from mac80211 are succesfully (re)transmitted frames and failed
frames.


--
Ciao
Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 26 Feb 2008 21:13:48 +0000
"Chris Clayton" wrote:

> And I will help in any way I can, providing diagnostics and trying patches.

Please, could you mount debugfs and provide me with a dump of this file:
/debug/ieee80211/phy*/stations/*/rc_pid_events

Thank you.


--
Ciao
Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 26/02/2008, Stefano Brivio wrote:
> On Tue, 26 Feb 2008 21:13:48 +0000
> "Chris Clayton" wrote:
>
> > And I will help in any way I can, providing diagnostics and trying patches.
>
>
> Please, could you mount debugfs and provide me with a dump of this file:
> /debug/ieee80211/phy*/stations/*/rc_pid_events
>

Here's a dump that I started, then began pinging my gateway in another
terminal until the network failed and then stopped the dump with ^C a
few seconds later. Hope it helps.

[chris:~]$ cat /debug/ieee80211/phy0/stations/00\:60\:b3\:77\:73\:1a/rc_pid_events
3 131904 tx_status 0 0
4 131904 pf_sample 0 3584 840 0
5 134212 tx_rate 0 10
6 134212 tx_status 0 0
7 134212 pf_sample 0 3584 1183 0
8 134212 tx_rate 0 10
9 134213 tx_status 0 1
10 134462 tx_rate 0 10
11 134462 tx_status 0 0
12 134462 pf_sample 8448 -4864 427 8448
13 134713 tx_rate 0 10
14 134713 tx_status 0 0
15 134713 pf_sample 0 3584 821 -8448
16 134713 rate_change 0 10
17 134964 tx_rate 0 10
18 134964 tx_status 0 0
19 134964 pf_sample 0 3584 1167 0
20 135215 tx_rate 0 10
21 135215 tx_status 0 0
22 135215 pf_sample 0 3584 1469 0
23 135215 rate_change 1 20
24 135466 tx_rate 1 20
25 135466 tx_status 0 0
26 135466 pf_sample 0 3584 1733 0
27 135466 rate_change 2 55
28 135717 tx_rate 2 55
29 135717 tx_status 0 0
30 135717 pf_sample 0 3584 1965 0
31 135717 rate_change 129 -541505508
32 135968 tx_rate 11 540
33 136219 tx_rate 11 540
34 136470 tx_rate 11 540
35 136721 tx_rate 11 540
36 136972 tx_rate 11 540
37 137223 tx_rate 11 540
38 137474 tx_rate 11 540
39 137725 tx_rate 11 540
40 137976 tx_rate 11 540
41 138227 tx_rate 11 540
^C


Chris

> Thank you.
>
>
> --
> Ciao
>
> Stefano
>

--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 26 Feb 2008 22:36:19 +0000
"Chris Clayton" wrote:

> 27 135466 rate_change 2 55
> 28 135717 tx_rate 2 55
> 29 135717 tx_status 0 0
> 30 135717 pf_sample 0 3584 1965 0
> 31 135717 rate_change 129 -541505508
> 32 135968 tx_rate 11 540

Known and fixed. The fix isn't in 2.6.25-rc3 yet, though.

Fix:
commit 32720eae675d08990e97bffbf71a31382599cc8a
Author: Stefano Brivio
Date: Tue Jan 29 20:29:16 2008 +0100

rc80211-pid: fix rate adjustment


--
Ciao
Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Feb 27, 2008 at 08:26:42AM +0100, Stefano Brivio wrote:
> On Tue, 26 Feb 2008 22:36:19 +0000
> "Chris Clayton" wrote:
>
> > 27 135466 rate_change 2 55
> > 28 135717 tx_rate 2 55
> > 29 135717 tx_status 0 0
> > 30 135717 pf_sample 0 3584 1965 0
> > 31 135717 rate_change 129 -541505508
> > 32 135968 tx_rate 11 540
>
> Known and fixed. The fix isn't in 2.6.25-rc3 yet, though.
>
> Fix:
> commit 32720eae675d08990e97bffbf71a31382599cc8a
> Author: Stefano Brivio
> Date: Tue Jan 29 20:29:16 2008 +0100
>
> rc80211-pid: fix rate adjustment

And it currently isn't queued for 2.6.25 at all.

Chris, can you cherry-pick this from the wireless-2.6.26 tree and
give it a test on your 2.6.25-rc3 tree? If it resolves a problem
then I'll queue it to Dave for 2.6.25 (which will probably provoke
a net-2.6.26 and wireless-2.6.26 rebase).

Let me know...

John
--
John W. Linville
linville@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Feb 27, 2008 at 10:51:11AM -0500, John W. Linville wrote:
> On Wed, Feb 27, 2008 at 08:26:42AM +0100, Stefano Brivio wrote:
> > On Tue, 26 Feb 2008 22:36:19 +0000
> > "Chris Clayton" wrote:
> >
> > > 27 135466 rate_change 2 55
> > > 28 135717 tx_rate 2 55
> > > 29 135717 tx_status 0 0
> > > 30 135717 pf_sample 0 3584 1965 0
> > > 31 135717 rate_change 129 -541505508
> > > 32 135968 tx_rate 11 540
> >
> > Known and fixed. The fix isn't in 2.6.25-rc3 yet, though.
> >
> > Fix:
> > commit 32720eae675d08990e97bffbf71a31382599cc8a
> > Author: Stefano Brivio
> > Date: Tue Jan 29 20:29:16 2008 +0100
> >
> > rc80211-pid: fix rate adjustment
>
> And it currently isn't queued for 2.6.25 at all.
>
> Chris, can you cherry-pick this from the wireless-2.6.26 tree and
> give it a test on your 2.6.25-rc3 tree? If it resolves a problem
> then I'll queue it to Dave for 2.6.25 (which will probably provoke
> a net-2.6.26 and wireless-2.6.26 rebase).

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?

Thanks,

John
--
John W. Linville
linville@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 27/02/2008, John W. Linville wrote:
> On Wed, Feb 27, 2008 at 10:51:11AM -0500, John W. Linville wrote:
> > On Wed, Feb 27, 2008 at 08:26:42AM +0100, Stefano Brivio wrote:
> > > On Tue, 26 Feb 2008 22:36:19 +0000
[...]
> > >
> > > Known and fixed. The fix isn't in 2.6.25-rc3 yet, though.
> > >
> > > Fix:
> > > commit 32720eae675d08990e97bffbf71a31382599cc8a
> > > Author: Stefano Brivio
> > > Date: Tue Jan 29 20:29:16 2008 +0100
> > >
> > > rc80211-pid: fix rate adjustment
> >
> > And it currently isn't queued for 2.6.25 at all.
> >
> > Chris, can you cherry-pick this from the wireless-2.6.26 tree and
> > give it a test on your 2.6.25-rc3 tree? If it resolves a problem
> > then I'll queue it to Dave for 2.6.25 (which will probably provoke
> > a net-2.6.26 and wireless-2.6.26 rebase).
>
>
> That might be easier said than done. It looks like that patch depends
> on the big cfg80211 API change queued for 2.6.26.
>

Yes, that's correct. The patch doesn't apply cleanly to -rc3 and,
having inspected at it, it looks too complicated for me to hack in.

> Stefano offered to rebase that on 2.6.25. Stefano, could you post
> that as part of this thread?
>

That would be very helpful.

Thanks
> Thanks,
>
>
> John
> --
> John W. Linville
> linville@tuxdriver.com
>


--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 27 Feb 2008 12:25:46 -0500
"John W. Linville" 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
---
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
- * Copyright 2007, Stefano Brivio
+ * Copyright 2007-2008, Stefano Brivio
*
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 02/03/2008, Stefano Brivio wrote:
> On Wed, 27 Feb 2008 12:25:46 -0500
> "John W. Linville" 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.
>

I've tested this with the pid algorithm selected and my wireless
network connection is reliable. In a loop, I repeatedly ftp'd a kernel
source tarball from another box on my network for 40 minutes with no
failure, whilst at the same time, pinging my gateway. Without the
patch, that activity would have led to network failure in seconds. The
tests were with the patch applied to 2.6.25-rc3-git3, so that Ivo's
rt2x00 patches for 2.6.25 are also applied.

Thanks to everyone who has helped fix this.

> ---
>
> 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

Tested-by: Chris Clayton

> ---
> 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
> - * Copyright 2007, Stefano Brivio
> + * Copyright 2007-2008, Stefano Brivio
> *
> * 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
>


--
Beauty is in the eye of the beerholder.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/