Re: [PATCH RFT] b43: We need lots of regression testing

Re: [PATCH RFT] b43: We need lots of regression testing

[Ronald]

hey all,

Can I safely apply this patch to the 2.6.25.1 kernel once it is 
released? I would love to test it... =)

(maybe a stupid question but I have no idea)

							Ronald

Re: [PATCH RFT] b43: We need lots of regression testing

[Pavel Roskin]

On Sun, 2008-04-06 at 10:23 +0200, Ronald wrote:
> hey all,
> 
> Can I safely apply this patch to the 2.6.25.1 kernel once it is 
> released? I would love to test it... =)
> 
> (maybe a stupid question but I have no idea)

The patch doesn't apply cleanly to the current main branch (linux-2.6),
and it's not likely to change before 2.6.25.1.

The conflicts are minor, but the patch would need to be adjusted.

If you want to test the patch, I suggest that you don't wait, but take
the current compat-wireless instead, patch it and compile it for you
current kernel.  It worked for me.

-- 
Regards,
Pavel Roskin

[PATCH RFT] b43: We need lots of regression testing

[Michael Buesch]

Hi b43 users,

Please be so kind to run lots of regression tests on the following
patch. This patch is supposed to make the LO calibration a _lot_ more
lightweight and avoid a long MAC-disable period every 120 seconds.

We need a lot of regression testing with this patch on lots of different
devices to make sure we don't introduce regressions.

I tested this on a 4306 and a 4318 card. So far it seems to work great
on these cards.

Thanks.


----------  Forwarded Message  ----------

Subject: Re: b43: 1 second "freeze" every 2 minutes - works with bcm43xx
Date: Friday 04 April 2008
From: Michael Buesch <mb@bu3sch.de>

Can you try the following patch?
http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch

This patch is supposed to distribute the calibration bursts over time,
so that calibration only happens when it's actually needed.
So instead of disabling the MAC every 120 secs and recalibrating the
whole calibration tables, we assign a timeout to each calibration value
and only recalibrate it if it's
a) expired and
b) currently used.
Recalibration might also happen on TX power adjustment, if the corresponding
calibration item is no longer in the cache because it has expired. That
actually happens most of the time, but we can live with it, as power adjustment
doesn't happen that often and calibration is a _lot_ cheaper.

This patch also reduced overall memory consumption by nuking the
huge static calibration tables.

Disclaimer:
The algorithms in this patch are completely redesigned and have nothing in
common with how broadcom does the stuff in the proprietary driver. So it's
highly experimental and I'm not responsible in case this patch eats your cat.

-------------------------------------------------------

-- 
Greetings Michael.

Re: [PATCH RFT] b43: We need lots of regression testing

[gavron]

Works great on my 4311 rev 01.
E

Michael Buesch wrote:
> Hi b43 users,
>
> Please be so kind to run lots of regression tests on the following
> patch. This patch is supposed to make the LO calibration a _lot_ more
> lightweight and avoid a long MAC-disable period every 120 seconds.
>
> We need a lot of regression testing with this patch on lots of different
> devices to make sure we don't introduce regressions.
>
> I tested this on a 4306 and a 4318 card. So far it seems to work great
> on these cards.
>
> Thanks.
>
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: b43: 1 second "freeze" every 2 minutes - works with bcm43xx
> Date: Friday 04 April 2008
> From: Michael Buesch <mb@bu3sch.de>
>
> Can you try the following patch?
> http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch
>
> This patch is supposed to distribute the calibration bursts over time,
> so that calibration only happens when it's actually needed.
> So instead of disabling the MAC every 120 secs and recalibrating the
> whole calibration tables, we assign a timeout to each calibration value
> and only recalibrate it if it's
> a) expired and
> b) currently used.
> Recalibration might also happen on TX power adjustment, if the corresponding
> calibration item is no longer in the cache because it has expired. That
> actually happens most of the time, but we can live with it, as power adjustment
> doesn't happen that often and calibration is a _lot_ cheaper.
>
> This patch also reduced overall memory consumption by nuking the
> huge static calibration tables.
>
> Disclaimer:
> The algorithms in this patch are completely redesigned and have nothing in
> common with how broadcom does the stuff in the proprietary driver. So it's
> highly experimental and I'm not responsible in case this patch eats your cat.
>
> -------------------------------------------------------
>
>   

Re: [PATCH RFT] b43: We need lots of regression testing

[Michael Buesch]

On Friday 04 April 2008 22:01:53 gavron@wetwork.net wrote:
> Works great on my 4311 rev 01.

Thanks a lot for testing!

> Michael Buesch wrote:
> > Hi b43 users,
> >
> > Please be so kind to run lots of regression tests on the following
> > patch. This patch is supposed to make the LO calibration a _lot_ more
> > lightweight and avoid a long MAC-disable period every 120 seconds.
> >
> > We need a lot of regression testing with this patch on lots of different
> > devices to make sure we don't introduce regressions.
> >
> > I tested this on a 4306 and a 4318 card. So far it seems to work great
> > on these cards.
> >
> > Thanks.
> >
> >
> > ----------  Forwarded Message  ----------
> >
> > Subject: Re: b43: 1 second "freeze" every 2 minutes - works with bcm43xx
> > Date: Friday 04 April 2008
> > From: Michael Buesch <mb@bu3sch.de>
> >
> > Can you try the following patch?
> > http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch
> >
> > This patch is supposed to distribute the calibration bursts over time,
> > so that calibration only happens when it's actually needed.
> > So instead of disabling the MAC every 120 secs and recalibrating the
> > whole calibration tables, we assign a timeout to each calibration value
> > and only recalibrate it if it's
> > a) expired and
> > b) currently used.
> > Recalibration might also happen on TX power adjustment, if the corresponding
> > calibration item is no longer in the cache because it has expired. That
> > actually happens most of the time, but we can live with it, as power adjustment
> > doesn't happen that often and calibration is a _lot_ cheaper.
> >
> > This patch also reduced overall memory consumption by nuking the
> > huge static calibration tables.
> >
> > Disclaimer:
> > The algorithms in this patch are completely redesigned and have nothing in
> > common with how broadcom does the stuff in the proprietary driver. So it's
> > highly experimental and I'm not responsible in case this patch eats your cat.
> >
> > -------------------------------------------------------

-- 
Greetings Michael.

Re: [PATCH RFT] b43: We need lots of regression testing

[Pavel Roskin]

On Fri, 2008-04-04 at 16:12 +0200, Michael Buesch wrote:
> Hi b43 users,
> 
> Please be so kind to run lots of regression tests on the following
> patch. This patch is supposed to make the LO calibration a _lot_ more
> lightweight and avoid a long MAC-disable period every 120 seconds.
> 
> We need a lot of regression testing with this patch on lots of different
> devices to make sure we don't introduce regressions.
> 
> I tested this on a 4306 and a 4318 card. So far it seems to work great
> on these cards.

Tested on this:

b43-phy0: Broadcom 4306 WLAN found
b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
phy0: Selected rate control algorithm 'pid'
Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]

It's actually Fedora development kernel 2.6.25-0.195.rc8.git1.fc9.i686
with patched compat-wireless installed.

It's working better than I could possibly expect.  The range is on the
par with another laptop with ipw3945 running Linux or Windows XP.  It's
working through 4 walls and 30 meters on top of that.  I understand that
there are many random factors involved, but my impression is very
positive.  Basically, it's good enough to go outside with the laptop
without having an AP installed near a window.  I haven't seen any
significant interruptions in the connection.

Unfortunately, I hit that nasty circular lock dependency bug (already
discussed in another thread) when I killed wpa_supplicant to try another
AP.  The CPU utilization went to 100%, but the driver kept working.

Another unrelated bug (sorry, testing often finds unrelated bugs) is
that scanning with specific ESSID was returning non-matching APs.  I
mean "iwlist wlan0 scan my_essid", which would still report many
different ESSIDs.  It's inconvenient when the driver can sense 22 APs at
once :)

I'll try to get 4318 tested over the weekend.

-- 
Regards,
Pavel Roskin

Re: [PATCH RFT] b43: We need lots of regression testing

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]


> Another unrelated bug (sorry, testing often finds unrelated bugs) is
> that scanning with specific ESSID was returning non-matching APs.  I
> mean "iwlist wlan0 scan my_essid", which would still report many
> different ESSIDs.  It's inconvenient when the driver can sense 22 APs at
> once :)

Heh. I'm not sure what the desired behaviour is, if you do that scan
we'll give you everything we found but will scan actively for that
particular SSID. The man page (sigh) only says:

              This command take optional arguments, however most drivers  will
              ignore  those.  The  option essid is used to specify a scan on a
              specific ESSID. The option last do not trigger a scan  and  read
              left-over scan results.

Which isn't quite clear, but seems to match what we do. Maybe iwlist
should filter it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH RFT] b43: We need lots of regression testing

[Pavel Roskin]

On Sat, 2008-04-05 at 11:09 +0200, Johannes Berg wrote:
> > Another unrelated bug (sorry, testing often finds unrelated bugs) i=
s
> > that scanning with specific ESSID was returning non-matching APs.  =
I
> > mean "iwlist wlan0 scan my_essid", which would still report many
> > different ESSIDs.  It's inconvenient when the driver can sense 22 A=
Ps at
> > once :)
>=20
> Heh. I'm not sure what the desired behaviour is, if you do that scan
> we'll give you everything we found but will scan actively for that
> particular SSID. The man page (sigh) only says:
>=20
> =EF=BB=BF              This command take optional arguments, however =
most drivers  will
>               ignore  those.  The  option essid is used to specify a =
scan on a
>               specific ESSID. The option last do not trigger a scan  =
and  read
>               left-over scan results.
>=20
> Which isn't quite clear, but seems to match what we do. Maybe iwlist
> should filter it?

I tried scanning for ESSID that no AP has.  Most time I only get
response from one AP, which is an old Linksys BEFW11S4 v4 (802.11b
only).  Sometimes one or two other APs appear.  But it some cases, all
22 or 23 APs in range appear in the list.

The easiest way to reproduce it is to scan without ESSID and then with
ESSID.  Then the second scan will return all APs found in the first
scan.  But run the scan with the ESSID several times, and at some point
the list goes down to that dumb Linksys.

I'm fine with scanning without filtering.  It's more important that we
let users control what probe requests are being sent.  But I think we
should be consistent and avoid returning results of scans with differen=
t
parameters.

--=20
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFT] b43: We need lots of regression testing

[gavron]

I had a case of total disassociation last night, and it is unusual.  NM 
was unable to reconnect (so we go to bash).
A scan revealed no APs but after a module reload they are back...
What further testing or other diagnostics can I run should this happen 
again to rest?
Thanks
E

[root@egdell ~]# iwlist wlan0 scan
wlan0     No scan results

[root@egdell ~]# rmmod b43
[root@egdell ~]# modprobe b43
[root@egdell ~]# iwlist wlan0 scan
wlan0     Scan completed :
          Cell 01 - Address: 00:16:01:B9:F9:3F
                    ESSID:"wetwork"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Channel:6
                    Quality=71/100  Signal level=-64 dBm  Noise 
level=-69 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=00000266671a2b44
          Cell 02 - Address: 00:16:01:B9:FE:8F
                    ESSID:"wetwork"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Channel:6
                    Quality=98/100  Signal level=-36 dBm  Noise 
level=-69 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=000002cd08cbc1ce
          Cell 03 - Address: 00:16:01:B9:F5:1F
                    ESSID:"wetwork"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Channel:6
                    Quality=61/100  Signal level=-74 dBm  Noise 
level=-69 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=0000021011e7a0e7

[root@egdell ~]#


Pavel Roskin wrote:
> On Fri, 2008-04-04 at 16:12 +0200, Michael Buesch wrote:
>   
>> Hi b43 users,
>>
>> Please be so kind to run lots of regression tests on the following
>> patch. This patch is supposed to make the LO calibration a _lot_ more
>> lightweight and avoid a long MAC-disable period every 120 seconds.
>>
>> We need a lot of regression testing with this patch on lots of different
>> devices to make sure we don't introduce regressions.
>>
>> I tested this on a 4306 and a 4318 card. So far it seems to work great
>> on these cards.
>>     
>
> Tested on this:
>
> b43-phy0: Broadcom 4306 WLAN found
> b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> phy0: Selected rate control algorithm 'pid'
> Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]
>
> It's actually Fedora development kernel 2.6.25-0.195.rc8.git1.fc9.i686
> with patched compat-wireless installed.
>
> It's working better than I could possibly expect.  The range is on the
> par with another laptop with ipw3945 running Linux or Windows XP.  It's
> working through 4 walls and 30 meters on top of that.  I understand that
> there are many random factors involved, but my impression is very
> positive.  Basically, it's good enough to go outside with the laptop
> without having an AP installed near a window.  I haven't seen any
> significant interruptions in the connection.
>
> Unfortunately, I hit that nasty circular lock dependency bug (already
> discussed in another thread) when I killed wpa_supplicant to try another
> AP.  The CPU utilization went to 100%, but the driver kept working.
>
> Another unrelated bug (sorry, testing often finds unrelated bugs) is
> that scanning with specific ESSID was returning non-matching APs.  I
> mean "iwlist wlan0 scan my_essid", which would still report many
> different ESSIDs.  It's inconvenient when the driver can sense 22 APs at
> once :)
>
> I'll try to get 4318 tested over the weekend.
>
>   

Re: [PATCH RFT] b43: We need lots of regression testing

[Pavel Roskin]

On Fri, 2008-04-04 at 23:06 -0400, Pavel Roskin wrote:

> I'll try to get 4318 tested over the weekend.

It's just as good as bcm4306.

b43-phy0: Broadcom 4318 WLAN found
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8

It was the same laptop in the same place, and I could even go a couple
of steps further than with bcm4306.  It's a place with 22 APs in range,
and the AP I was connecting to is installed in a brick building away
from any windows.  Yet I could maintain connection at the far end of the
paring lot nearby.

I realize that the unpatched drive could probably perform as well.  But
I wanted to use this opportunity to test the driver and the patch at
once in some real life conditions, and the results are great!

Another thing I noticed today is that the quality next to the AP is
normally from 65/100 to 75/100.  But sometimes it jumps to a higher
number momentarily, up to 130/100.  Yet I don't see corresponding
changes in the signal and noise when it happens.  Signal level is
jumping randomly from -55 dBm to -15 dBm, and noise level is always -72
dBm (rarely -71 dBm).

When at the place when the connection breaks, the quality is 30/100,
the signal level is -84 dBm and the noise level is still -72 dBm.

Perhaps the quality could be calibrated so that 30 becomes 0 and 70
becomes 100 (and we should never get quality over 100).  The noise level
is probably too high.  And the signal jumping 40 dBm without me even
touching anything may indicate that the driver probably fails to make
some adjustments in the signal value.

-- 
Regards,
Pavel Roskin