Re: 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, Feb 26, 2008 at 07:11:39PM +, 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 [EMAIL PROTECTED] -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, Feb 26, 2008 at 07:11:39PM +, 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 [EMAIL PROTECTED] -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 <[EMAIL PROTECTED]> 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"
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Fri, 2008-02-22 at 07:39 +, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
On Friday 22 February 2008, Chris Clayton wrote:
> Hi Ivo,
>
> On 18/02/2008, Ivo van Doorn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Friday 22 February 2008, Chris Clayton wrote: > On Thursday 21 February 2008, Chris Vine wrote: > > On Thu, 2008-02-21 at 23:04 +, 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/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. > > > > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, On 18/02/2008, Ivo van Doorn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, On 18/02/2008, Ivo van Doorn [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Friday 22 February 2008, Chris Clayton wrote: On Thursday 21 February 2008, Chris Vine wrote: On Thu, 2008-02-21 at 23:04 +, 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/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. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
On Friday 22 February 2008, Chris Clayton wrote:
Hi Ivo,
On 18/02/2008, Ivo van Doorn [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Fri, 2008-02-22 at 07:39 +, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Thursday 21 February 2008, Chris Vine wrote: > On Thu, 2008-02-21 at 23:04 +, 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/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. > > 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: 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 > > Chris > > > > -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Thursday 21 February 2008, Chris Vine wrote: > On Wed, 2008-02-20 at 21:16 +, 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? Ivo -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wed, 2008-02-20 at 21:16 +, 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. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wed, 2008-02-20 at 21:16 +, 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. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Thursday 21 February 2008, Chris Vine wrote: On Wed, 2008-02-20 at 21:16 +, 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? Ivo -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Thursday 21 February 2008, Chris Vine wrote: On Thu, 2008-02-21 at 23:04 +, 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/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. 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: 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 Chris -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, [...] > > 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. > Sorry, but again a few pings and the network fails. I've attached the before and after register dumps. This is with your patch applied against 2.6.25-rc2-git4. Chris -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x68 2 0x18 3 0x00 4 0x11 5 0x0b 6 0x01 7 0x38 8 0x00 9 0x00 10 0x02 11 0x04 12 0x00 13 0x15 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x6e 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x06 41 0x60 42 0x09 43 0x00 44 0x4e 45 0x96 46 0xc1 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x02 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0xcf 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x00033e80 26 0x1010 27 0xc78f 28 0x96dc8ba9 29 0x00a0 30 0x 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x00014300 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 90 0x 91 0x 92 0x 93 0x 94 0x 95 0x 96 0x 97 0x 98 0x 99 0x 100 0x 101 0x 102 0x 103 0x 104 0x 105 0x 106 0x 107 0x 108 0x 109 0x 110 0x 111 0x 112 0x 113 0x 114 0x 115 0x 116 0x 117 0x 118 0x 119 0x 120 0x 121 0x 122 0x 123 0x 124 0x 125 0x 126 0x 127 0x 128 0x 129 0x 130 0x 131 0x 132 0x 133 0x 134 0x 135 0x 136 0x 137 0x 138 0x 139 0x 140 0x 141 0x 142 0x 143 0x 144 0x 145 0x 146 0x 147 0x 148 0x 149 0x 150 0x 151 0x 152 0x 153 0x 154 0x 155 0x 156 0x 157 0x 158 0x 159 0x 160 0x 161 0x 162 0x 163 0x 164 0x 165 0x 166 0x 167 0x 168 0x 169 0x 170 0x 171 0x 172 0x 173 0x 174 0x 175 0x 176 0x 177 0x 178 0x 179 0x 180 0x 181 0x 182 0x 183 0x 184 0x 185 0x 186 0x 187 0x 188 0x 189 0x 190 0x 191 0x 192 0x 193 0x 194 0x 195 0x 196 0x 197 0x 198 0x 199 0x 200 0x 201 0x 202 0x 203 0x 204 0x 205 0x 206 0x 207 0x 208 0x 209 0x 210 0x 211 0x 212 0x 213 0x 214 0x 215 0x 216 0x 217 0x 218 0x 219 0x 220 0x 221 0x 222 0x 223 0x 224 0x 225 0x 226 0x 227 0x 228 0x 229 0x 230 0x 231 0x 232 0x 233 0x 234 0x 235 0x 236
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
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. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wednesday 20 February 2008, Chris Vine wrote: > > On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: > > On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: > > > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > > > > Hi, > > > > > > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > There are specific moments that should be dumped: > > > > > > > > - kernel 2.6.24 (last known working version for you). > > > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > > > > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies > > > > > after a few pings. > > > > > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 > > > kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the > > > stick in but I then get a complete kernel lock up with two flashing > > > leds. Nothing is recorded to system logs. The last logged messages are > > > that usbcore has registered new interface driver rt73usb, and that the > > > rate control algorithm has been selected on phy0. This happens whether > > > the simple or pid mac80211 rate control algorithms have been chosen. > > > > > > This is a shame because 2.0.14 was working really well for me until the > > > mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the > > > release of 2.1.*). > > > > Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a > > picture of the panic if one shows up. _Something_ should show up on the > > VT. > > 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. --- diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c index b63bc66..460ef2f 100644 --- a/drivers/net/wireless/rt2x00/rt2400pci.c +++ b/drivers/net/wireless/rt2x00/rt2400pci.c @@ -953,8 +953,12 @@ static int rt2400pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2400pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2400pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c index add8aff..ffcd996 100644 --- a/drivers/net/wireless/rt2x00/rt2500pci.c +++ b/drivers/net/wireless/rt2x00/rt2500pci.c @@ -1106,8 +1106,12 @@ static int rt2500pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c index d9643c5..9f59db9 100644 --- a/drivers/net/wireless/rt2x00/rt2500usb.c +++ b/drivers/net/wireless/rt2x00/rt2500usb.c @@ -996,8 +996,12 @@ static int rt2500usb_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500usb_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500usb_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: > On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: > > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > > > Hi, > > > > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > > > > > 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. > > > > > > > > > > > > > > There are specific moments that should be dumped: > > > > > > > - kernel 2.6.24 (last known working version for you). > > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies > > > > after a few pings. > > > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 > > kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the > > stick in but I then get a complete kernel lock up with two flashing > > leds. Nothing is recorded to system logs. The last logged messages are > > that usbcore has registered new interface driver rt73usb, and that the > > rate control algorithm has been selected on phy0. This happens whether > > the simple or pid mac80211 rate control algorithms have been chosen. > > > > This is a shame because 2.0.14 was working really well for me until the > > mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the > > release of 2.1.*). > > Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a > picture of the panic if one shows up. _Something_ should show up on the > VT. 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! There is a complete lock up. Even the two leds don't send a dump in morse code (if that is still a feature of the 2.6 kernels). They just flash together at 1 second intervals. However, I do not have debugging enabled on 2.6.25-rc2 (I was just interested to see how it worked). If it is thought to be useful I can recompile the kernel with debugging enabled, but this should be reproducible by anyone with a rt73 stick. By way of a further data point, I can scan OK using 2.6.25-rc2 and it will report all the available access points in my area. But as soon as association is attempted, it blows up. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > > Hi, > > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > > > 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. > > > > > > > > > > > > There are specific moments that should be dumped: > > > > > > - kernel 2.6.24 (last known working version for you). > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies after > > > a few pings. > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 > kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the > stick in but I then get a complete kernel lock up with two flashing > leds. Nothing is recorded to system logs. The last logged messages are > that usbcore has registered new interface driver rt73usb, and that the > rate control algorithm has been selected on phy0. This happens whether > the simple or pid mac80211 rate control algorithms have been chosen. > > This is a shame because 2.0.14 was working really well for me until the > mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the > release of 2.1.*). Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a picture of the panic if one shows up. _Something_ should show up on the VT. Dan -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the stick in but I then get a complete kernel lock up with two flashing leds. Nothing is recorded to system logs. The last logged messages are that usbcore has registered new interface driver rt73usb, and that the rate control algorithm has been selected on phy0. This happens whether the simple or pid mac80211 rate control algorithms have been chosen. This is a shame because 2.0.14 was working really well for me until the mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the release of 2.1.*). Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a picture of the panic if one shows up. _Something_ should show up on the VT. Dan -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the stick in but I then get a complete kernel lock up with two flashing leds. Nothing is recorded to system logs. The last logged messages are that usbcore has registered new interface driver rt73usb, and that the rate control algorithm has been selected on phy0. This happens whether the simple or pid mac80211 rate control algorithms have been chosen. This is a shame because 2.0.14 was working really well for me until the mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the release of 2.1.*). Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a picture of the panic if one shows up. _Something_ should show up on the VT. 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! There is a complete lock up. Even the two leds don't send a dump in morse code (if that is still a feature of the 2.6 kernels). They just flash together at 1 second intervals. However, I do not have debugging enabled on 2.6.25-rc2 (I was just interested to see how it worked). If it is thought to be useful I can recompile the kernel with debugging enabled, but this should be reproducible by anyone with a rt73 stick. By way of a further data point, I can scan OK using 2.6.25-rc2 and it will report all the available access points in my area. But as soon as association is attempted, it blows up. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wednesday 20 February 2008, Chris Vine wrote: On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the stick in but I then get a complete kernel lock up with two flashing leds. Nothing is recorded to system logs. The last logged messages are that usbcore has registered new interface driver rt73usb, and that the rate control algorithm has been selected on phy0. This happens whether the simple or pid mac80211 rate control algorithms have been chosen. This is a shame because 2.0.14 was working really well for me until the mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the release of 2.1.*). Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a picture of the panic if one shows up. _Something_ should show up on the VT. 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. --- diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c index b63bc66..460ef2f 100644 --- a/drivers/net/wireless/rt2x00/rt2400pci.c +++ b/drivers/net/wireless/rt2x00/rt2400pci.c @@ -953,8 +953,12 @@ static int rt2400pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2400pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2400pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c index add8aff..ffcd996 100644 --- a/drivers/net/wireless/rt2x00/rt2500pci.c +++ b/drivers/net/wireless/rt2x00/rt2500pci.c @@ -1106,8 +1106,12 @@ static int rt2500pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c index d9643c5..9f59db9 100644 --- a/drivers/net/wireless/rt2x00/rt2500usb.c +++ b/drivers/net/wireless/rt2x00/rt2500usb.c @@ -996,8 +996,12 @@ static int rt2500usb_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500usb_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500usb_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c index 46888f9..a1d8e33 100644 --- a/drivers/net/wireless/rt2x00/rt2x00config.c +++
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
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. Chris -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, [...] 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. Sorry, but again a few pings and the network fails. I've attached the before and after register dumps. This is with your patch applied against 2.6.25-rc2-git4. Chris -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x68 2 0x18 3 0x00 4 0x11 5 0x0b 6 0x01 7 0x38 8 0x00 9 0x00 10 0x02 11 0x04 12 0x00 13 0x15 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x6e 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x06 41 0x60 42 0x09 43 0x00 44 0x4e 45 0x96 46 0xc1 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x02 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0xcf 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x00033e80 26 0x1010 27 0xc78f 28 0x96dc8ba9 29 0x00a0 30 0x 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x00014300 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 90 0x 91 0x 92 0x 93 0x 94 0x 95 0x 96 0x 97 0x 98 0x 99 0x 100 0x 101 0x 102 0x 103 0x 104 0x 105 0x 106 0x 107 0x 108 0x 109 0x 110 0x 111 0x 112 0x 113 0x 114 0x 115 0x 116 0x 117 0x 118 0x 119 0x 120 0x 121 0x 122 0x 123 0x 124 0x 125 0x 126 0x 127 0x 128 0x 129 0x 130 0x 131 0x 132 0x 133 0x 134 0x 135 0x 136 0x 137 0x 138 0x 139 0x 140 0x 141 0x 142 0x 143 0x 144 0x 145 0x 146 0x 147 0x 148 0x 149 0x 150 0x 151 0x 152 0x 153 0x 154 0x 155 0x 156 0x 157 0x 158 0x 159 0x 160 0x 161 0x 162 0x 163 0x 164 0x 165 0x 166 0x 167 0x 168 0x 169 0x 170 0x 171 0x 172 0x 173 0x 174 0x 175 0x 176 0x 177 0x 178 0x 179 0x 180 0x 181 0x 182 0x 183 0x 184 0x 185 0x 186 0x 187 0x 188 0x 189 0x 190 0x 191 0x 192 0x 193 0x 194 0x 195 0x 196 0x 197 0x 198 0x 199 0x 200 0x 201 0x 202 0x 203 0x 204 0x 205 0x 206 0x 207 0x 208 0x 209 0x 210 0x 211 0x 212 0x 213 0x 214 0x 215 0x 216 0x 217 0x 218 0x 219 0x 220 0x 221 0x 222 0x 223 0x 224 0x 225 0x 226 0x 227 0x 228 0x 229 0x 230 0x 231 0x 232 0x 233 0x 234 0x 235 0x 236 0x 237
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > Hi, > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > 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. > > > > > > > > > > There are specific moments that should be dumped: > > > > > - kernel 2.6.24 (last known working version for you). > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies after a > > few pings. rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the stick in but I then get a complete kernel lock up with two flashing leds. Nothing is recorded to system logs. The last logged messages are that usbcore has registered new interface driver rt73usb, and that the rate control algorithm has been selected on phy0. This happens whether the simple or pid mac80211 rate control algorithms have been chosen. This is a shame because 2.0.14 was working really well for me until the mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the release of 2.1.*). Chris -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, > > > I've tried the patch but, unfortunately, my wireless LAN still dies after > > > a few pings. > > > > Could you use below patch instead, and make a new dump of the register? > > I'm still convinced the breakage occurs in the antenna diversity (or > > rather, I believe > > it attempts a software diversity for your card while in fact it shouldn't). > > > > Sorry, I've applied that patch and the LAN still dies after a few pings. BTW, > this and the earlier patch both apply without error, but give warnings of 70 > line offsets. Were you expecting them to apply completely cleanly? I'm just > wondering if there might be some code that you are expecting to be running (or > not running) that is (or is not) present in the driver at 2.6.25-rc2. Well to be honest I based the patch on rt2x00.git and not 2.6.25-rc2. I know the patch would apply safely because the function that were changed in that patch haven't changed between them. But some other functions were moved. So that offset is correct. ;) > The register dumps before and after are attached. Thanks. I hope to have a new patch ready soon. Ivo -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, On Tuesday 19 February 2008, Ivo van Doorn wrote: > Hi, > [...] > > > > I've tried the patch but, unfortunately, my wireless LAN still dies after a > > few pings. > > Could you use below patch instead, and make a new dump of the register? > I'm still convinced the breakage occurs in the antenna diversity (or rather, > I believe > it attempts a software diversity for your card while in fact it shouldn't). > Sorry, I've applied that patch and the LAN still dies after a few pings. BTW, this and the earlier patch both apply without error, but give warnings of 70 line offsets. Were you expecting them to apply completely cleanly? I'm just wondering if there might be some code that you are expecting to be running (or not running) that is (or is not) present in the driver at 2.6.25-rc2. The register dumps before and after are attached. Thanks, Chris > > The frame dump diagnostics you asked for are attached. This is a fresh dump > > taken > > tonight running the driver with your patch applied. > > Thanks, I think I miss some information in that dump, > but that is okay for now. > > Ivo > > --- > > diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c > b/drivers/net/wireless/rt2x00/rt2x00dev.c > index 015738a..65a512f 100644 > --- a/drivers/net/wireless/rt2x00/rt2x00dev.c > +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c > @@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct > rt2x00_dev *rt2x00dev) >* sample the rssi from the other antenna to make a valid >* comparison between the 2 antennas. >*/ > - if ((rssi_curr - rssi_old) > -5 || (rssi_curr - rssi_old) < 5) > + if (abs(rssi_curr - rssi_old) < 5) > return; > > rt2x00dev->link.ant.flags |= ANTENNA_MODE_SAMPLE; > @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct > rt2x00_dev *rt2x00dev) > rt2x00dev->link.ant.flags &= ~ANTENNA_TX_DIVERSITY; > > if (rt2x00dev->hw->conf.antenna_sel_rx == 0 && > - rt2x00dev->default_ant.rx != ANTENNA_SW_DIVERSITY) > + rt2x00dev->default_ant.rx == ANTENNA_SW_DIVERSITY) > rt2x00dev->link.ant.flags |= ANTENNA_RX_DIVERSITY; > if (rt2x00dev->hw->conf.antenna_sel_tx == 0 && > - rt2x00dev->default_ant.tx != ANTENNA_SW_DIVERSITY) > + rt2x00dev->default_ant.tx == ANTENNA_SW_DIVERSITY) > rt2x00dev->link.ant.flags |= ANTENNA_TX_DIVERSITY; > > if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) && > > -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x78 2 0x18 3 0x00 4 0x11 5 0x0b 6 0x01 7 0x38 8 0x00 9 0x00 10 0x02 11 0x04 12 0x00 13 0x15 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x73 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x04 41 0x60 42 0x09 43 0x01 44 0x34 45 0x37 46 0x94 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x01 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0x00 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x00033e80 26 0x1010 27 0xc78f 28 0x41a6223c 29 0x008b 30 0x 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x4200 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 90 0x 91 0x 92 0x 93 0x 94 0x 95 0x 96 0x 97 0x 98 0x 99 0x
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > 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. > > > > > > > > There are specific moments that should be dumped: > > > > - kernel 2.6.24 (last known working version for you). > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > Thanks. I think I found something, please test below patch: > > > > I've tried the patch but, unfortunately, my wireless LAN still dies after a > few pings. Could you use below patch instead, and make a new dump of the register? I'm still convinced the breakage occurs in the antenna diversity (or rather, I believe it attempts a software diversity for your card while in fact it shouldn't). > The frame dump diagnostics you asked for are attached. This is a fresh dump > taken > tonight running the driver with your patch applied. Thanks, I think I miss some information in that dump, but that is okay for now. Ivo --- diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c index 015738a..65a512f 100644 --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct rt2x00_dev *rt2x00dev) * sample the rssi from the other antenna to make a valid * comparison between the 2 antennas. */ - if ((rssi_curr - rssi_old) > -5 || (rssi_curr - rssi_old) < 5) + if (abs(rssi_curr - rssi_old) < 5) return; rt2x00dev->link.ant.flags |= ANTENNA_MODE_SAMPLE; @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev) rt2x00dev->link.ant.flags &= ~ANTENNA_TX_DIVERSITY; if (rt2x00dev->hw->conf.antenna_sel_rx == 0 && - rt2x00dev->default_ant.rx != ANTENNA_SW_DIVERSITY) + rt2x00dev->default_ant.rx == ANTENNA_SW_DIVERSITY) rt2x00dev->link.ant.flags |= ANTENNA_RX_DIVERSITY; if (rt2x00dev->hw->conf.antenna_sel_tx == 0 && - rt2x00dev->default_ant.tx != ANTENNA_SW_DIVERSITY) + rt2x00dev->default_ant.tx == ANTENNA_SW_DIVERSITY) rt2x00dev->link.ant.flags |= ANTENNA_TX_DIVERSITY; if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) && -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, > > 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. > > > > There are specific moments that should be dumped: > > - kernel 2.6.24 (last known working version for you). > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: --- diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c index 015738a..8df1991 100644 --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev) rt2x00dev->link.ant.flags &= ~ANTENNA_TX_DIVERSITY; if (rt2x00dev->hw->conf.antenna_sel_rx == 0 && - rt2x00dev->default_ant.rx != ANTENNA_SW_DIVERSITY) + rt2x00dev->default_ant.rx == ANTENNA_SW_DIVERSITY) rt2x00dev->link.ant.flags |= ANTENNA_RX_DIVERSITY; if (rt2x00dev->hw->conf.antenna_sel_tx == 0 && - rt2x00dev->default_ant.tx != ANTENNA_SW_DIVERSITY) + rt2x00dev->default_ant.tx == ANTENNA_SW_DIVERSITY) rt2x00dev->link.ant.flags |= ANTENNA_TX_DIVERSITY; if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) && -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: --- diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c index 015738a..8df1991 100644 --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev) rt2x00dev-link.ant.flags = ~ANTENNA_TX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_rx == 0 - rt2x00dev-default_ant.rx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.rx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_RX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_tx == 0 - rt2x00dev-default_ant.tx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.tx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_TX_DIVERSITY; if (!(rt2x00dev-link.ant.flags ANTENNA_RX_DIVERSITY) -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. Could you use below patch instead, and make a new dump of the register? I'm still convinced the breakage occurs in the antenna diversity (or rather, I believe it attempts a software diversity for your card while in fact it shouldn't). The frame dump diagnostics you asked for are attached. This is a fresh dump taken tonight running the driver with your patch applied. Thanks, I think I miss some information in that dump, but that is okay for now. Ivo --- diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c index 015738a..65a512f 100644 --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct rt2x00_dev *rt2x00dev) * sample the rssi from the other antenna to make a valid * comparison between the 2 antennas. */ - if ((rssi_curr - rssi_old) -5 || (rssi_curr - rssi_old) 5) + if (abs(rssi_curr - rssi_old) 5) return; rt2x00dev-link.ant.flags |= ANTENNA_MODE_SAMPLE; @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev) rt2x00dev-link.ant.flags = ~ANTENNA_TX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_rx == 0 - rt2x00dev-default_ant.rx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.rx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_RX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_tx == 0 - rt2x00dev-default_ant.tx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.tx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_TX_DIVERSITY; if (!(rt2x00dev-link.ant.flags ANTENNA_RX_DIVERSITY) -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, On Tuesday 19 February 2008, Ivo van Doorn wrote: Hi, [...] I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. Could you use below patch instead, and make a new dump of the register? I'm still convinced the breakage occurs in the antenna diversity (or rather, I believe it attempts a software diversity for your card while in fact it shouldn't). Sorry, I've applied that patch and the LAN still dies after a few pings. BTW, this and the earlier patch both apply without error, but give warnings of 70 line offsets. Were you expecting them to apply completely cleanly? I'm just wondering if there might be some code that you are expecting to be running (or not running) that is (or is not) present in the driver at 2.6.25-rc2. The register dumps before and after are attached. Thanks, Chris The frame dump diagnostics you asked for are attached. This is a fresh dump taken tonight running the driver with your patch applied. Thanks, I think I miss some information in that dump, but that is okay for now. Ivo --- diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c index 015738a..65a512f 100644 --- a/drivers/net/wireless/rt2x00/rt2x00dev.c +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c @@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct rt2x00_dev *rt2x00dev) * sample the rssi from the other antenna to make a valid * comparison between the 2 antennas. */ - if ((rssi_curr - rssi_old) -5 || (rssi_curr - rssi_old) 5) + if (abs(rssi_curr - rssi_old) 5) return; rt2x00dev-link.ant.flags |= ANTENNA_MODE_SAMPLE; @@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev *rt2x00dev) rt2x00dev-link.ant.flags = ~ANTENNA_TX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_rx == 0 - rt2x00dev-default_ant.rx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.rx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_RX_DIVERSITY; if (rt2x00dev-hw-conf.antenna_sel_tx == 0 - rt2x00dev-default_ant.tx != ANTENNA_SW_DIVERSITY) + rt2x00dev-default_ant.tx == ANTENNA_SW_DIVERSITY) rt2x00dev-link.ant.flags |= ANTENNA_TX_DIVERSITY; if (!(rt2x00dev-link.ant.flags ANTENNA_RX_DIVERSITY) -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x78 2 0x18 3 0x00 4 0x11 5 0x0b 6 0x01 7 0x38 8 0x00 9 0x00 10 0x02 11 0x04 12 0x00 13 0x15 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x73 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x04 41 0x60 42 0x09 43 0x01 44 0x34 45 0x37 46 0x94 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x01 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0x00 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x00033e80 26 0x1010 27 0xc78f 28 0x41a6223c 29 0x008b 30 0x 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x4200 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 90 0x 91 0x 92 0x 93 0x 94 0x 95 0x 96 0x 97 0x 98 0x 99 0x 100 0x 101 0x 102 0x 103 0x 104 0x 105
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. Could you use below patch instead, and make a new dump of the register? I'm still convinced the breakage occurs in the antenna diversity (or rather, I believe it attempts a software diversity for your card while in fact it shouldn't). Sorry, I've applied that patch and the LAN still dies after a few pings. BTW, this and the earlier patch both apply without error, but give warnings of 70 line offsets. Were you expecting them to apply completely cleanly? I'm just wondering if there might be some code that you are expecting to be running (or not running) that is (or is not) present in the driver at 2.6.25-rc2. Well to be honest I based the patch on rt2x00.git and not 2.6.25-rc2. I know the patch would apply safely because the function that were changed in that patch haven't changed between them. But some other functions were moved. So that offset is correct. ;) The register dumps before and after are attached. Thanks. I hope to have a new patch ready soon. Ivo -- 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/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: Hi, [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. Thanks. I think I found something, please test below patch: I've tried the patch but, unfortunately, my wireless LAN still dies after a few pings. rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the stick in but I then get a complete kernel lock up with two flashing leds. Nothing is recorded to system logs. The last logged messages are that usbcore has registered new interface driver rt73usb, and that the rate control algorithm has been selected on phy0. This happens whether the simple or pid mac80211 rate control algorithms have been chosen. This is a shame because 2.0.14 was working really well for me until the mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the release of 2.1.*). Chris -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, On Monday 18 February 2008, Ivo van Doorn wrote: > Hi, > > > 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. > It will be tomorrow before I can provide this because I'm struggling to get wireshark to build against the old (2.4.x) kernel headers that match glibc on my laptop. I'll build it on my desktop, which has more recent headers, and decode the frame dump there. But I need sleep now :) > > [chris:~]$ uname -a > > Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686 > > GNU/Linux > > [chris:~]$ ping 192.168.1.1 > > PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data. > > 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec > > 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec > > 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec > > 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. > > There are specific moments that should be dumped: > - kernel 2.6.24 (last known working version for you). > - kernel 2.6.25-rc2 (after ifup, before TX dies) > - kernel 2.6.25-rc2 (after ifup, after TX dies) > These diagnostics are attached, with obvious filenames. > > I will be more than happy to provide additional diagnostics, but > > please bear in mind that I am not a git user, so cannot do bisects. I > > am, however, perfectly capable of applying or reverting patches, > > rebuilding and re-testing, so I am quite happy to do that. > > 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 > > No further bisecting is needed, but with above tests I can at least > narrow it down to find the cause of this issue. > > Thanks. > > Ivo > -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x88 2 0x00 3 0x00 4 0x12 5 0x0b 6 0x10 7 0x00 8 0x00 9 0x00 10 0x00 11 0x04 12 0x00 13 0x70 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x74 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x04 41 0x60 42 0x0d 43 0x7c 44 0x4d 45 0x75 46 0xdf 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x02 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0x00 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x000b3e80 26 0x1010 27 0xc78f 28 0x0fe4bcfe 29 0x0078 30 0x71e7 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x0800 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86
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 -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, > 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. > [chris:~]$ uname -a > Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686 > GNU/Linux > [chris:~]$ ping 192.168.1.1 > PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data. > 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec > 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec > 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) > I will be more than happy to provide additional diagnostics, but > please bear in mind that I am not a git user, so cannot do bisects. I > am, however, perfectly capable of applying or reverting patches, > rebuilding and re-testing, so I am quite happy to do that. 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 No further bisecting is needed, but with above tests I can at least narrow it down to find the cause of this issue. Thanks. Ivo debugfsdump.sh Description: application/shellscript
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, 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. [chris:~]$ uname -a Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686 GNU/Linux [chris:~]$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) I will be more than happy to provide additional diagnostics, but please bear in mind that I am not a git user, so cannot do bisects. I am, however, perfectly capable of applying or reverting patches, rebuilding and re-testing, so I am quite happy to do that. 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 No further bisecting is needed, but with above tests I can at least narrow it down to find the cause of this issue. Thanks. Ivo debugfsdump.sh Description: application/shellscript
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 -- 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/
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi Ivo, On Monday 18 February 2008, Ivo van Doorn wrote: Hi, 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. It will be tomorrow before I can provide this because I'm struggling to get wireshark to build against the old (2.4.x) kernel headers that match glibc on my laptop. I'll build it on my desktop, which has more recent headers, and decode the frame dump there. But I need sleep now :) [chris:~]$ uname -a Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686 GNU/Linux [chris:~]$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec 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. There are specific moments that should be dumped: - kernel 2.6.24 (last known working version for you). - kernel 2.6.25-rc2 (after ifup, before TX dies) - kernel 2.6.25-rc2 (after ifup, after TX dies) These diagnostics are attached, with obvious filenames. I will be more than happy to provide additional diagnostics, but please bear in mind that I am not a git user, so cannot do bisects. I am, however, perfectly capable of applying or reverting patches, rebuilding and re-testing, so I am quite happy to do that. 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 No further bisecting is needed, but with above tests I can at least narrow it down to find the cause of this issue. Thanks. Ivo -- Beauty is in the eye of the beerholder. BBP: 0 0x16 1 0x88 2 0x00 3 0x00 4 0x12 5 0x0b 6 0x10 7 0x00 8 0x00 9 0x00 10 0x00 11 0x04 12 0x00 13 0x70 14 0x18 15 0x30 16 0x2c 17 0x40 18 0x06 19 0x00 20 0x1e 21 0xc8 22 0x38 23 0x06 24 0xfe 25 0x0a 26 0x0d 27 0x27 28 0x06 29 0x00 30 0x74 31 0x2b 32 0x14 33 0x55 34 0x12 35 0x50 36 0x11 37 0x07 38 0x00 39 0xf8 40 0x04 41 0x60 42 0x0d 43 0x7c 44 0x4d 45 0x75 46 0xdf 47 0x6e 48 0x04 49 0x00 50 0x2a 51 0x00 52 0xee 53 0x10 54 0x18 55 0x00 56 0x10 57 0x08 58 0x02 59 0x08 60 0x10 61 0x04 62 0x04 63 0x00 64 0x01 65 0x03 66 0x00 67 0x00 68 0x00 69 0x00 70 0x26 71 0x00 72 0x00 73 0x00 74 0xff 75 0xfe 76 0x40 77 0x00 78 0x00 79 0x00 80 0x05 81 0x14 82 0x50 83 0xc0 84 0x10 85 0x00 86 0xfe 87 0x40 88 0xfe 89 0x40 90 0x0f 91 0x08 92 0x00 93 0x00 94 0x06 95 0x08 96 0x48 97 0x48 98 0x48 99 0x00 100 0x20 101 0x06 102 0x16 103 0x00 104 0x2c 105 0x20 106 0x90 107 0x04 108 0x04 109 0x00 110 0x00 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0x00 123 0x00 124 0x00 125 0x00 126 0x00 127 0x00 CSR: 0 0x0002561c 1 0x0004 2 0xde501100 3 0x00fff404 4 0x77b36000 5 0x00031a73 6 0x0fff 7 0x 8 0x013a030a 9 0xa314 10 0x071c 11 0x000a0050 12 0x0009 13 0xe060 14 0x00071e46 15 0x 16 0x027eb162 17 0x9eaa9eaf 18 0x8a8b8c8d 19 0x00858687 20 0x740a0732 21 0x015f 22 0x0a143870 23 0x2e31353b 24 0x2a2a2a2c 25 0x000b3e80 26 0x1010 27 0xc78f 28 0x0fe4bcfe 29 0x0078 30 0x71e7 31 0x000f 32 0x0001 33 0x23b0 34 0x82188200 35 0xff00 36 0x150cca0b 37 0x060a100c 38 0x00080606 39 0x0a08 40 0x 41 0x 42 0x 43 0x 44 0x 45 0x 46 0x 47 0x 48 0x 49 0x 50 0x 51 0x 52 0x0800 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x0300 59 0x 60 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 0x 67 0x 68 0x 69 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 0x 79 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 90 0x 91
