b43: We need lots of regression testing

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 <[email protected]>

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.

Works great on my 4311 rev 01.
E

Thanks a lot for testing!

Greetings Michael.

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

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

s

I

Ps at

most drivers will

scan on a

and read

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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 ~]#

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