Re: [PATCH] b43: Rewrite DMA Tx status handling sanity checks
On Nov 23, 2009, at 11:49 AM, Michael Buesch wrote: On Monday 23 November 2009 05:45:47 Larry Finger wrote: On 11/19/2009 03:24 PM, Michael Buesch wrote: This rewrites the error handling policies in the TX status handler. It tries to be error-tolerant as in try hard to not crash the machine. It won't recover from errors (that are bugs in the firmware or driver), because that's impossible. However, it will return a more or less useful error message and bail out. It also tries hard to use rate-limited messages to not flood the syslog in case of a failure. This patch definitely helped open-source firmware, but it is not a complete fix. It is no fix _at_ _all_. The patch does not change a single line of code that wasn't either an assertion or a machine crash before. So it just transforms assertions into more verbose assertions and crashes into assertions without a crash. debug: Out of order TX status report on DMA ring 1. Expected 114, but got 146 Ok, this is what I expected. Let's see what's going on. Here's the ring. o is unused, * is used. ooo ***ooo ^ ^ ^ 114 146 newest oldest So as you can see, the firmware reported a TX status for a frame right in the middle of the ringbuffer. The new code detects this now before getting a double free and/or silent memory corruption (freeing of used memory). Hi Michael, so you can observe this behavior at your site. Do you mind describing the exact configuration? Maybe this time I can reproduce this behavior, as I tried everything to make it happen. I also asked Larry one of his boards and put it into several PCs but had no chance to reproduce the crash. Could you please also report the neighboring stations, the AP you are connected and so on. Many thanks, -Francesco Informativa sulla privacy: http://help.ing.unibs.it/privacy.php ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 515668] New: kernel BUG at drivers/net/wireless/b43/dma.c:1406! when using openfwwf firmware
On Aug 5, 2009, at 1:07 PM, Peter Lemenkov wrote: Hello,All! Here is a bug report regarding DMA issues with openfwwf ver. 5.2 . I suspect, that this is a known issue, but anyway, maybe this bugzilla ticket will add something important. Hi Peter, many thanks. I added a note on the website. I have a few cards like that, I will do some tests to catch the bug. Cheers, -FG -- Forwarded message -- From: bugzi...@redhat.com Date: 2009/8/5 Subject: [Bug 515668] New: kernel BUG at drivers/net/wireless/b43/dma.c:1406! when using openfwwf firmware To: lemen...@gmail.com Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: kernel BUG at drivers/net/wireless/b43/dma.c:1406! when using openfwwf firmware https://bugzilla.redhat.com/show_bug.cgi?id=515668 Summary: kernel BUG at drivers/net/wireless/b43/dma.c:1406! when using openfwwf firmware Product: Fedora Version: 11 Platform: i686 OS/Version: Linux Status: NEW Severity: urgent Priority: low Component: b43-openfwwf AssignedTo: lemen...@gmail.com ReportedBy: arethus...@gmail.com QAContact: extras...@fedoraproject.org CC: lemen...@gmail.com Estimated Hours: 0.0 Classification: Fedora User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090717 Fedora/3.5.1-3.fc11 Firefox/3.5.1 I am using a Linksys PCMCIA wireless card, which is model WPC54GS at version 2, on a Fedora 11 system installed on a Thinkpad T42. When I am using the b43 kernel module in conjunction with the b43-openfwwf firmware, I frequently observe the system panic when there is heavy amounts of network activity on the wireless card interface. Empirically, this issue only seems to happen when the card is associated with the residential wireless network broadcast by the Actiontec MI424WR wireless router, and it does not occur when using the Broadcom firmware extracted according to the instructions from http://www.linuxwireless.org/en/users/Drivers/b43#device_firmware. I can most consistently cause a crash by using the speed testing service at http://www.speedtest.net/ to stress test the wireless interface. Reproducible: Always Steps to Reproduce: 1. Install b43-openfwwf to get the wireless card operational. 2. Visit http://www.speedtest.net/ for an easy way to stress test the card. 3. Start a speed test. The kernel should panic shortly after the test is begun. Actual Results: The system halts with a kernel panic. Expected Results: The system should not crash. I captured the resulting kernel panic using netconsole, since the system did not switch to a text console when the panic occurred. The information from lspci -vv regarding the card is: 03:00.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) Subsystem: Linksys Device 0049 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Interrupt: pin A routed to IRQ 11 Region 0: Memory at c400 (32-bit, non-prefetchable) [size=8K] Kernel driver in use: b43-pci-bridge Kernel modules: ssb -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug. -- With best regards, Peter Lemenkov. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https
Re: [Bug 515668] New: kernel BUG at drivers/net/wireless/b43/dma.c:1406! when using openfwwf firmware
On Aug 5, 2009, at 4:41 PM, Larry Finger wrote: Francesco Gringoli wrote: On Aug 5, 2009, at 1:07 PM, Peter Lemenkov wrote: Hello,All! Here is a bug report regarding DMA issues with openfwwf ver. 5.2 . I suspect, that this is a known issue, but anyway, maybe this bugzilla ticket will add something important. Hi Peter, many thanks. I added a note on the website. I have a few cards like that, I will do some tests to catch the bug. Francesco, This bug is the same as the one I reported for both my 4311 and my 4318. When the TX status interrupt is entered for a particular cookie, the skb is freed, and the buffer pointer is replaced with a NULL. The kernel panic reported here is the result of detecting a NULL value for that buffer pointer. I think the conclusion is that the firmware is calling the interrupt routine with a cookie that was previously reported. Why? I don't know. Even with the source to look at, firmware is a big mystery. Hi Larry, D'oh!... so I already had some boards which displayed that behavior!! Ok ok, I will have two more (if the two minipci-e I bought will ever arrive, I'm still waiting) :-) Taking back my old laptop with PCMCIA slot. Cheers, -Francesco Larry INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA queue overflow
On Jul 30, 2009, at 9:02 PM, Larry Finger wrote: Francesco, skb=NULL somehow smells like a double-free caused by a double-report or something like that. Based on what Michael said about a double-free, I changed from meta-skb = NULL to meta-skb = 0x0606060606060606, and changed to testing section apropriately. Now I got two messages, then the interface hung, probably due to a bogus skb that was not NULL: b43: meta data: skb 0606060606060606 dmaaddr 20a320bc is_last_fragment 1 b43: ring data: nr_slots 256 used_slots 241 current_slot 87 index 1 tx 1 max_used_slots 256 b43: cookie: 0x2062 slot: 99 b43: meta data: skb 0606060606060606 dmaaddr 279220bc is_last_fragment 1 b43: ring data: nr_slots 256 used_slots 252 current_slot 147 index 1 tx 1 max_used_slots 256 b43: cookie: 0x2044 slot: 69 It certainly looks as if txstatus is called more than once with the same cookie. Larry Hi Larry, many thanks. I will surely look into that direction as soon as I get the boards. By the way: I never worked with mini-pci-e and I don't even have a desktop PC with that bus, so I plan to get some newer desktop around in my department and use a pci-e to mini-pci-e adapter. Do you know if such adapter can trigger some incompatibility with b43? Or is it completely transparent? Cheers, -Francesco INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA queue overflow
On Jul 30, 2009, at 11:55 PM, Michael Buesch wrote: On Thursday 30 July 2009 23:54:17 Francesco Gringoli wrote: many thanks. I will surely look into that direction as soon as I get the boards. By the way: I never worked with mini-pci-e and I don't even have a desktop PC with that bus, so I plan to get some newer desktop around in my department and use a pci-e to mini-pci-e adapter. Do you know if such adapter can trigger some incompatibility with b43? Or is it completely transparent? I think it's just a mechanical adapter. Thanks, I will get one immediately. Cheers, -Francesco INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: DMA queue overflow
On Jul 26, 2009, at 7:01 PM, Larry Finger wrote: Michael Buesch wrote: On Sunday 26 July 2009 17:37:10 Larry Finger wrote: The revised printk shows b43-phy0 warning: DMA queue overflow with free_slots = 0 Ok, it's a mac80211 bug then. Perhaps not. I also got the ring-stopped WARN_ON. Is it possible that a second transmission was held at the spin_lock_irqsave() when the queues were stopped. If that were the case, the following patch should fix the problem. [cut] I do have one question. Should the DMA queue overflow message ever be printed? It seems to me that we have a 'no harm - no foul' situation. Larry Larry, is this stuff related in some way to the error triggered by the opensource firmware? What happens with your patch? I still have not received the boards so I have not started working on it, I'm waiting them from Hong Kong. Cheers, -Francesco INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Improved opensource firmware
Hello there, after a long time we just made available a new version of the opensource firmware at http://www.ing.unibs.it/openfwwf (release 5.2). We discovered a bug that was causing the firmware to go into suspension after a phy error due to external conditions: syslog reported a phy error and the mac suspended, interface was no more usable. This bug appears usually when the signal received from the peer is very low, and was reported by several users. Now we can still have phy errors in the system.log but the interface remains fully functional (as it happens with the official firmware). There are also more comments in the source code with some registers explained. Larry, I think this could be one of the causes of the malfunctioning you reported before. If you have some time (and indeed if you feel like doing it :-) ) please test this firmware, it will be great. Cheers, -Francesco INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione privacy. Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFC] b44: Add fw capabilities
===
--- wireless-testing.orig/drivers/net/wireless/b43/pio.c 2009-04-08
02:10:23.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/pio.c 2009-04-08
02:10:38.0 +0200
@@ -313,7 +313,7 @@ static struct b43_pio_txqueue *select_qu
{
struct b43_pio_txqueue *q;
-if (b43_modparam_qos) {
+if (dev-qos_enabled) {
/* 0 = highest priority */
switch (queue_prio) {
default:
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Apr 6, 2009, at 5:04 PM, Michael Buesch wrote: Well, you know that lots of cards don't work correctly with b43. I bet you're using a BCM4318 flavor. Sadly, yes, it is a BCM4318. I've tried moving further away from the AP, as well as decreasing the txpower output.. neither seemed to help any. I suspect something else may be the cause of the poor performance that I'm seeing. I'll try to rule out the card as a problem tonight by setting up an Ad-Hoc network under Windows XP. If I observe good performance then maybe b43 is the issue... In which case.. I'll start the painful process of comparing the Windows driver to b43. If I find any discrepancies, I'll send them to the reverse engineers to be posted with the rest of the specs. Then maybe you or someone else can make the appropriate changes to b43. 4318 currently is not usable in AP mode due to low but (for AP mode) significant packet loss in high transmission rates. I doubt this will change unless Broadcom releases some code. Michael, is this for all 4318? I'm doing extensive testing these days with both 4318 and 4306 on x86. I always get very good performance with latest hostapd on 2.6.29-rc2-wl. I can also reach maximum theoretical throughput if I choose channel 14 to limit interferences. I get max throughput independently of the board running hostapd and traffic direction. All this applies to both AP and stations being x86 linux based, e.g., if I try to join an x86 AP running b43 from my macbook I can get good performance only occasionally. Good performance also if the station is a linksys wrt54gl (it uses a 4318). I can't instead run hostapd successfully on these linksys. Cheers, -FG I suggest you just buy another card instead of wasting months of time on trying to get this to work. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
quetion on beacon irq and multibss
Michael, I was wondering about the beacon IRQ and those functions inside b43 that handle such interrupt. In which situations apart the first installation of the beacon in template ram, is handle_irq_beacon called inside the b43 driver? E.g., openfirmware does not raise the beacon irq but beaconing is correct and it has no problem in AP mode. Is this function useful for multibss? e.g., after we send a beacon the kernel can upload the next one and so on... Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Apr 10, 2009, at 12:42 AM, Michael Buesch wrote: On Friday 10 April 2009 00:28:48 Francesco Gringoli wrote: You mean that it misses to transmit some frames? Do you have hypotheses on why AP mode should complete change the behavior of the board from good enough to not working correctly? Practice shows this. It's as simple as that. Try it, if you don't trust me. No no, I didn't want to say that I don't trust what you say, I too experienced problems with 4318 on linksys. I'm wondering what could be the problem, I was asking if you have any conjecture about. Of course, there always are exceptions to these rules, because there are about a million completely different 4318 and and 4306 cards out there. So you might be lucky to pick one of the few 4318 that works well in AP mode, or you might pick one of the few 4306 that don't work too well. Ok, that could be. I have only 4318 branded as Asus, they are all equal. Probably the fact the linksys does not work in AP mode confirm what you say. I mostly use linksys products for testing. But I think I could give the asus card a try, if you say it works better in AP mode. Ok that could be nice. Mine is a mini-pci card, it was a very common board included in WL500G Premium AP. I have noticed, however a strange fact with these 4318 based linksys: when I set one of them in AP mode, beaconing is perfect and I can join it from other stations. When I ping the AP from stations I get echo reply. If, instead, I ping stations from the AP, no packet is sent! at all; if I telnet from stations to the AP, e.g., to port 22, 3whs ends but then the TCP session dies. The strange fact is that it seems that there are problems for all the frames whose generation involves a contest switching from userspace to kernel, in other words a complete cross of the mac80211+b43 layers. If instead, on the AP, I completely bypass the network stack and directly ask b43 to transmit a frame (with a modified b43) the frame is transmitted, at every rate I choose (I choose the rate inside the kernel code, I'm not referring to the rate set by iwconfig). Do you have some of these flawed 4318? I don't think the type of device influences whether packets are dropped inside of some random kernel subsystem. -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: quetion on beacon irq and multibss
On Apr 10, 2009, at 12:44 AM, Michael Buesch wrote: On Friday 10 April 2009 00:34:32 Francesco Gringoli wrote: I was wondering about the beacon IRQ and those functions inside b43 that handle such interrupt. In which situations apart the first installation of the beacon in template ram, is handle_irq_beacon called inside the b43 driver? E.g., openfirmware does not raise the beacon irq but beaconing is correct and it has no problem in AP mode. Is this function useful for multibss? e.g., after we send a beacon the kernel can upload the next one and so on... It's raised when the beacon needs to be updated. Think about TIM, for example. This is not used for MBSS. I thought this was handled inside the firmware so we put the same refreshing code back and forth from template to shm for the tim part. Ok but what`about MBSS? Is it already implemented in b43? I found some old patches from Johannes but they required fw hacking, I can't find traces of them inside the current kernel. So I would assume MBSS is not yet implemented. If openfw does not raise the interrupt, PS most likely is broken and the firmware cannot work on AP with PS stations associated. Uh, interesting. I completely missed this. I must say I'm not familiar with PS. Many thanks, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Refresh RX poison on buffer recycling
On Mar 30, 2009, at 11:35 PM, Francesco Gringoli wrote:
On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:
The RX buffer poison needs to be refreshed, if we recycle an RX
buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: sta...@kernel.org
Cc: Francesco Gringoli francesco.gring...@ing.unibs.it
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Francesco, please stresstest this on top of the other patch that
adds poisoning.
Hi Michael,
great work! No more crashes with the two patches. I will continue
stress testing anyway but it seems stable.
Hi Michael,
I run the patched kernel for some time and, though it is stable and
never crashes, there are still (few) some strange rx events. I will
refer to them as Wrong Frame Type I, Type II, and III. Please note
however, that we can observe them ONLY when the FCSFAIL bit is set in
the mac_ctrl_high (at least in my setup).
- Type I: plcp length mismatch
These frames have a plcp that seems to be correct (I mean, the first
two bytes appear to be taken from a valid plcp), the padding reported
by the firmware in this cases is correct too (e.g. the padding always
point to the byte where the valid plcp seems to start). HOWEVER, the
length of such frames is different than the length encoded in their
plcp. In all these frames the B43_RX_MAC_FCSERR bit is not set, though
these frames will fail a crc check. We should check the plcp matches
the skb length and manually set the RX_FLAG_FAILED_FCS_CRC bit in the
status field so that mac80211 will skip these frames.
- Type II: fcs is wrong
These frames have a correct plcp that matches their skb length. Their
FCS however is wrong! but the B43_RX_MAC_FCSERR is not set. Again we
should manually set the RX_FLAG_FAILED_FCS_CRC bit in the status field
so that mac80211 will skip these frames. I believe that these frames
are nothing more than Type I but the broken length collided with their
actual length.
- Type III: plcp is not a... plcp
These frames have a plcp that is not a plcp, in the sense that the
first two bytes (with both padding 0 or 2) does not represent any
possible plcp.
I attach a patch to correctly set the RX_FLAG_FAILED_FCS_CRC bit in
the status field on such situations so that such frames are not passed
to the upper layers.
Cheers,
-FG
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===
--- drivers/net/wireless/b43/xmit.c 2009-03-26 19:41:53.0 +0100
+++ drivers/net/wireless/b43/xmit.c 2009-03-27 20:55:31.0 +0100
@@ -27,6 +27,7 @@
*/
+#include linux/crc32.h
#include xmit.h
#include phy_common.h
#include dma.h
@@ -560,6 +562,67 @@
goto drop;
}
plcp = (struct b43_plcp_hdr6 *)(skb-data + padding);
+
+ if ((dev-wl-filter_flags FIF_FCSFAIL) !(macstat
B43_RX_MAC_FCSERR)) {
+ int mismatch = 0;
+ int skb_len = skb-len - 6 - padding;
+ u8* plcp_data = (u8*) plcp;
+ if (phystat0 B43_RX_PHYST0_OFDM) {
+ int pkt_len = plcp_data[0] |
+ plcp_data[1] 8 |
+ plcp_data[2] 16 |
+ plcp_data[3] 24;
+ pkt_len = 5;
+ pkt_len = 0xFFF;
+ if(pkt_len != skb_len) {
+ mismatch = 1;
+ }
+ }
+ else {
+ int speed;
+ int len1 = (plcp_data[3] 8) | plcp_data[2];
+ int len2;
+ switch(plcp_data[0]) {
+ case 0x0A:
+ speed = 2;
+ break;
+ case 0x14:
+ speed = 4;
+ break;
+ case 0x37:
+ speed = 11;
+ break;
+ case 0x6E:
+ speed = 22;
+ break;
+ default:
+ speed = 1;
+ break;
+ }
+ len2 = skb_len * 16 / speed;
+ if((skb_len * 16 % speed) 0)
+ len2++;
+
+ if(len1 != len2) {
+ mismatch = 1;
+ }
+ }
+ if(mismatch) {
+ dev-wl-ieee_stats.dot11FCSErrorCount++;
+ macstat |= B43_RX_MAC_FCSERR;
+ status.flag |= RX_FLAG_FAILED_FCS_CRC;
+ plcp_data = (u8*) (struct b43_plcp_hdr6 *)(skb-data);
+ b43dbg(dev-wl, RX: padding or plcp
Re: [PATCH] b43: Refresh RX poison on buffer recycling
On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:
The RX buffer poison needs to be refreshed, if we recycle an RX
buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: sta...@kernel.org
Cc: Francesco Gringoli francesco.gring...@ing.unibs.it
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Francesco, please stresstest this on top of the other patch that
adds poisoning.
Hi Michael,
great work! No more crashes with the two patches. I will continue
stress testing anyway but it seems stable.
I have one more question: the hardware seems to allow frames that are
longer than 2352 bytes. If we monitor the firmware during receiving we
get up to 0x1005 bytes long frames. When such frames arrives, the
kernel drops them as the The data did not fit into one descriptor
buffer and is split over multiple buffers. I tried to increase
B43_DMA0_RX_BUFFERSIZE up to 0x1006 but I get problems with dma and
the driver keeps restarting the hardware forever. What is wrong with
increasing this value above IEEE80211_MAX_FRAME_LEN?
Many thanks,
Cheers
-FG
John, please queue as bugfix.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2009-03-27
23:15:36.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-03-27
23:30:17.0 +0100
@@ -1503,20 +1503,16 @@ static void dma_rx(struct b43_dmaring *r
len = le16_to_cpu(rxhdr-frame_len);
} while (len == 0 i++ 5);
if (unlikely(len == 0)) {
- /* recycle the descriptor buffer. */
- sync_descbuffer_for_device(ring, meta-dmaaddr,
-ring-rx_buffersize);
- goto drop;
+ dmaaddr = meta-dmaaddr;
+ goto drop_recycle_buffer;
}
}
if (unlikely(b43_rx_buffer_is_poisoned(ring, skb))) {
/* Something went wrong with the DMA.
* The device did not touch the buffer and did not overwrite
the
poison. */
b43dbg(ring-dev-wl, DMA RX: Dropping poisoned buffer.\n);
- /* recycle the descriptor buffer. */
- sync_descbuffer_for_device(ring, meta-dmaaddr,
-ring-rx_buffersize);
- goto drop;
+ dmaaddr = meta-dmaaddr;
+ goto drop_recycle_buffer;
}
if (unlikely(len ring-rx_buffersize)) {
/* The data did not fit into one descriptor buffer
@@ -1530,6 +1526,7 @@ static void dma_rx(struct b43_dmaring *r
while (1) {
desc = ops-idx2desc(ring, *slot, meta);
/* recycle the descriptor buffer. */
+ b43_poison_rx_buffer(ring, meta-skb);
sync_descbuffer_for_device(ring, meta-dmaaddr,
ring-rx_buffersize);
*slot = next_slot(ring, *slot);
@@ -1548,8 +1545,7 @@ static void dma_rx(struct b43_dmaring *r
err = setup_rx_descbuffer(ring, desc, meta, GFP_ATOMIC);
if (unlikely(err)) {
b43dbg(ring-dev-wl, DMA RX: setup_rx_descbuffer() failed\n);
- sync_descbuffer_for_device(ring, dmaaddr, ring-rx_buffersize);
- goto drop;
+ goto drop_recycle_buffer;
}
unmap_descbuffer(ring, dmaaddr, ring-rx_buffersize, 0);
@@ -1559,6 +1555,11 @@ static void dma_rx(struct b43_dmaring *r
b43_rx(ring-dev, skb, rxhdr);
drop:
return;
+
+drop_recycle_buffer:
+ /* Poison and recycle the RX buffer. */
+ b43_poison_rx_buffer(ring, skb);
+ sync_descbuffer_for_device(ring, dmaaddr, ring-rx_buffersize);
}
void b43_dma_rx(struct b43_dmaring *ring)
--
Greetings, Michael.
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Poison RX buffers
On Mar 28, 2009, at 12:53 AM, Michael Buesch wrote: On Saturday 28 March 2009 00:49:12 Francesco Gringoli wrote: On Mar 27, 2009, at 10:51 PM, Michael Buesch wrote: This patch adds poisoning and sanity checking to the RX DMA buffers. This is used for protection against buggy hardware/firmware that raises RX interrupts without doing an actual DMA transfer. This mechanism protects against rare bad packets (due to uninitialized skb data) and rare kernel crashes due to uninitialized RX headers. Francesco, please stresstest this. Hi Michael, thank you for the patch, I will test it ASAP. Before testing, however, I would like to have a feedback about sanity checking directly the rxhdr. Two reasons: 1) also with the patch I sent you yesterday, I continued to observe kernel freezing with FCSFAIL set 2) I fear that when dma_rx is triggered with such dma events, also the content of rxhdr can be broken. In particular if the rxhdr-len reports an incredible long frame, dma_rx could begin recycling too many skbs. I was reported (by Bo) that when this happens, kernel would likely freeze. This should be fixed by this patch as well. Yes you are right :-) sorry. Testing tomorrow, pc is crashed in my office now. I'll let you know. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Poison RX buffers
. */
+ b43dbg(ring-dev-wl, DMA RX: Dropping poisoned buffer.\n);
+ /* recycle the descriptor buffer. */
+ sync_descbuffer_for_device(ring, meta-dmaaddr,
+ring-rx_buffersize);
+ goto drop;
+ }
if (unlikely(len ring-rx_buffersize)) {
/* The data did not fit into one descriptor buffer
* and is split over multiple buffers.
--
Greetings, Michael.
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Mask PHY TX error interrupt, if not debugging
On Mar 19, 2009, at 7:27 PM, Michael Buesch wrote: This masks the PHY TX error interrupt, if debugging is disabled. Currently we have a bug somewhere which triggers this interrupt once in a while. (Depends on the network noise/quality). While this is nonfatal, Michael, some time ago I begin seeing several of these errors, never seen before on one of my host, with both proprietary and open firmwares. As I never noticed those errors before, I wondered if they could be due to some strange frame received by air, something like a frame encoded in CCK but with a broken field that caused the firmware to ack back a frame whose first byte (encoding) didn't match the following inside the plcp. That was obviously not the case, indeed those errors were not even happening on tx tries and surprisingly they were happening also on devices configured in monitor mode. I finally remembered that the day before starting observing errors, I changed the minipci to pci adapter inside that host, maintaining the same cable and antenna set. Removing the broken adapter stopped PHY errors. After this debug session I have some notes - PHY error IRQs are not triggered by the firmware (both open and proprietary) by writing to the IRQ registers - these strange PHY errors are not due to tx tries, they happen also with devices were the tx code has been cut away - PHY errors are triggered by the hardware when the number of bytes requested for transmission do not match the tx information stored in the first four bytes of the plcp, this happens for both frames sent by b43 through dma and frames composed by the firmware. If everything is consistent I never see errors on platforms not affected by noise (as my old VIA or the broken minipci to pci adapter). I would say this noise directly affects the irq line, or it triggers the serializer to send out a packet with completely wrong radio/plcp/ mac configuration that causes a PHY tx error. Cheers, -FG it scares the hell out of users and we frequently receive bugreports that incorrectly identify this error message as the reason. There's another problem with this. The PHY TX error interrupt is protected with a watchdog that will restart the device if it keeps triggering very often. This is used to fix interrupt storms from completely broken devices. However, this watchdog might trigger in completely normal operation. If the TX capacity of the card is saturated, the likeliness of the watchdog triggering increases, as more TX errors occur. The current threshold for the watchdog is 1000 errors in 15 seconds. This patch adds a workaround for the issue by just enabling the interrupt if debugging is disabled (by Kconfig or by modparam). This has the downside that real fatal PHY TX errors are not caught anymore. But this is nonfatal due to the following reasons: * If the card is not able to transmit anymore, MLME will notice anyway. * I did _never_ see a real fatal PHY TX error in a mainline b43 driver. * It does _not_ result in interrupt storms or something like that. It will simply result in a stalled card. It can be debugged by enabling the debugging module parameter. Signed-off-by: Michael Buesch m...@bu3sch --- I wonder how much placebo PHY TX error was fixed and my card performs great again we will get. :D !!! DISTRIBUTIONS !!! Disable CONFIG_B43_DEBUG! There is absolutely _no_ reason to enable it on a release kernel. There were valid reasons in the past, but there are none left anymore. So please _disable_ this option now, if you didn't do this already, because with CONFIG_B43_DEBUG enabled the PHY TX errors will still show. John, please merge this for the next feature release. Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-03-19 17:27:39.0 +0100 +++ wireless-testing/drivers/net/wireless/b43/main.c 2009-03-19 18:53:16.0 +0100 @@ -3990,12 +3990,14 @@ static void setup_struct_wldev_for_init( setup_struct_phy_for_init(dev, dev-phy); /* IRQ related flags */ dev-irq_reason = 0; memset(dev-dma_reason, 0, sizeof(dev-dma_reason)); dev-irq_savedstate = B43_IRQ_MASKTEMPLATE; + if (b43_modparam_verbose B43_VERBOSITY_DEBUG) + dev-irq_savedstate = ~B43_IRQ_PHY_TXERR; dev-mac_suspended = 1; /* Noise calculation context */ memset(dev-noisecalc, 0, sizeof(dev-noisecalc)); } -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX
Re: [PATCH] b43: Mask PHY TX error interrupt, if not debugging
On Mar 19, 2009, at 8:13 PM, Michael Buesch wrote: On Thursday 19 March 2009 20:00:45 Francesco Gringoli wrote: Yeah well. This confirms my thoughts. There are other ways to voluntarily trigger the errors. For example try covering the antennae with your bare hands. Try to move the device to a place with extremely bad signal (Iron beams between them). Try to move the transceivers very close (20cm) together, so basic rf rules are violated. This are all pretty reliable ways to trigger these errors. Cool! I will give it a try. - these strange PHY errors are not due to tx tries, they happen also with devices were the tx code has been cut away Well, I did not see that, so I cannot really comment on this. I never saw them in monitor mode. It was the reason that made me lose a lot of time in putting traps into the firmware to understand if we were forgetting something in configuring devices to run in monitor mode. Well, we are not: the tx code is never crossed. But PHY errors are triggered the same. I would say this noise directly affects the irq line, or it triggers the serializer to send out a packet with completely wrong radio/plcp/ mac configuration that causes a PHY tx error. I don't think it triggers the IRQ line. I'd rather think that some sensitivity threshold is configured incorrectly, so the PHY will trigger the errors on completely valid stuff. I would agree with you, but there is this bizarre issue with PHY errors in monitoring mode that makes me thinking about what we call PHY errors. I would say they are not only due to transmission, they are general PHY errors, could they be? One last test I could try, is to put again the broken minipci to pci adapter in one pci slot and put on the next slot the adapter that does not trigger these errors. If the interference caused by the broken adapter induces the wifi boards on top of it in errors, it should induce the same error on the board mounted on the right adapter. Cheers, -FG So now this is your turn: Which one? :D -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Mask PHY TX error interrupt, if not debugging
On Mar 19, 2009, at 9:10 PM, Michael Buesch wrote: On Thursday 19 March 2009 20:56:52 Francesco Gringoli wrote: I would agree with you, but there is this bizarre issue with PHY errors in monitoring mode that makes me thinking about what we call PHY errors. I would say they are not only due to transmission, they are general PHY errors, could they be? One last test I could try, is No the interrupt indicates a PHY TX error. This name is from the broadcom headers, so we can trust that it's correct. As I said, I never saw the error with the proprietary firmware in monitor mode. If you know a way how to trigger them, please tell me. It should be pretty easy, if you can observe these errors in sta mode (for instance with the cool method you told me before), you should see the same errors also in monitor mode, that is what was happening with my two adapters mounted on the same pci raiser (one with four minipci slots, unfortunately broken as when I use it I see PHY errors). Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 on via cpu
Hello everyone, I tried without success to run b43 on a via (cpu) pc and I got a very strange behavior. Everything seems to work fine for a random time going from 60s to a multiple of 60s. Then dmesg reports that a direct probe failed and that b43 lost the connection to the AP. I tried both ubuntu and slackware (thinking it could be due to ubuntu network manager) and always with kernel 2.6.29-rc2-wl, the same I'm using on all my development platforms (and I never got problems with). I had the same problem with a number of BCM adapters so it was not due to the wifi adapters. I took the same hardware and same kernel to other platforms not via based and the problem disappeared: the only difference was the VIA cpu instead of anyone else not VIA. If it can worth I can report more details on the VIA architecture I was using, but I don't know if there is anyone who cares about :-) Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
On Feb 17, 2009, at 11:54 PM, Michael Buesch wrote: Please read the code. There are lots of sanity checks in b43 and mac80211 that make it impossible to receive completely corrupted frames. I reconsidered this message because I too did some tests in capturing frames with proprietary firmware. As Bo said, we can capture corrupted frames with R351 but we can't with R410. The reason is that this firmware seems to not even check whether or not bit B43_MACCTL_KEEP_BAD is set so I believe no kernel patch could correct this problem, because it is on the firmware side. Cheers, -FG On Tuesday 17 February 2009 23:05:51 Bo Han wrote: Hi, I am interested in capturing FCS error frames using b43 driver. My hardware information is as follows. b43-phy9: Broadcom 4318 WLAN found b43-phy9 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy9 debuf: Found Radio: Manuf 0x17f, Version 0x2050, Revision 8 I am using firmware version 410.2160 with linux kernel version 2.6.27.10. I told the firmware to keep the bad frames by setting ctl |= B43_MACCTL_KEEP_BAD just before b43_write32(dev, b43_MMIO_MACCTL, ctl) in b43_adjust_mode(...) in main.c. From b43_rx(...) in xmit.c, I can only see packets dropped because their rate_idx == -1. The length of all the dropped packets is 80 bytes and they look like the following: 8fae 0308 0b01 0085 1500 482c 50b3 0b01 0085 5fa0 1500 482c 50b3 0003 850b cdcc 1b00 1d00 b945 c0cd b905 630a 5e10 0101 0601 0b06 000b 07d6 bab9 addb 35fd 33e8 cd8f 8eaa 6f77 b9e8 However, there is still no packet received with macstat B43_RX_MAC_FCSERR. I also tried the 351 firmware for which I saw several FCS error frames in PIO mode. But the sniffing tools like Wireshark cannot get any packets. including the correct ones, when using that firmware. Am I missing something? Thanks, -Bo -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More data on open-source firmware crash
On Feb 22, 2009, at 8:10 PM, Larry Finger wrote: Francesco and Lorenzo, I modified my driver source to dump the firmware machine state whenever the b43_dma_handle_txstatus routine was called with an out-of-order cookie. With proprietary firmware, the test of a flood ping in one job and repeated tcpperf transmissions in a second ran for 10 hours without a single failure. With the open-source firmware it failed after about 2 hours. Below are the saved status data. Listed for each item are the cookie, the sequence number, and the skb length. The 0x84 length values come from the ping. All of the out-of-order items come from tcpperf - is it significant that they are from the longer set? Note that a number of cookie/sequence pairs are missing, namely: 2064/9C1, 2066/9C2, 2068/9C3, 206A/9C4, 206C/9C5, 2072/9C7, 2076/9C9, and 207A/9CB. Cookie 206E is missing, but the next sequence (9C6) was attached to cookie 2070. Larry, do you mind testing this firmware? It's not the solution, but can help us understanding if we should follow this way. Download at http://www.ing.unibs.it/~gringoli/fwtest.tar.gz Before using this firmware please recompile b43 changing these two definitions in b43.h #define B43_MARKER_ID_REG 52 #define B43_MARKER_LINE_REG 53 I coded the firmware so that it will raise a B43_DEBUGIRQ_MARKER with id 10, line 100 if the condition I'm thinking to is true. You will see (I hope) in dmesg. Thanks, bye -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
On Feb 18, 2009, at 11:15 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 03:33:01 Francesco Gringoli wrote:
On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 00:07:56 Bo Han wrote:
I think I am working on the first sanity check in the driver, but
still
cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD
the only
thing we need to do for the firmware?
No. I suggest you don't touch that flag anyway and change the
corresponding
mac80211 filter flag. You most likely can do that through cfg80211/
nl80211/iw.
It will take care to set the b43 flag.
Michael is right, the new iw interface eases all this stuff.
There are however a few points that should be discussed
- why b43_rx(...) (in xmit.c) does not mark the status with
RX_FLAG_FAILED_FCS_CRC when the firmware reports a B43_RX_MAC_FCSERR:
IMHO this should be done to prevent mac80211 to be corrupted and
crash
the pc when a _very_ noisy frame arrives
Well, I think the mac80211 flag was invented afterwards. Remember
that b43
was the first mac80211 driver ever and quite a few things didn't
exist when
I ported the stuff.
So do you care to send a patch?
ok, I will send.
Anyway, could you elaborate why you think it would _crash_? I think
it shouldn't
crash in any case.
No. But I have to analyze more because I think there is a problem with
the firmware too (all firmwares) that not always sets up correctly the
corrupted frame flag when the KEEP_BAD_FRAME bit is activated. I will
check this and what happens when KEEP_BAD_FRAME is set and we have a
mistake even at the plcp sublayer (see below).
However, if RX_FLAG_FAILED_FCS_CRC is not set up in the status field,
mac80211 will process this frame: should not be something related to
the skb, probably somewhere it is shortened without checking its
actual size, as mac80211 trusts the driver that should already had
checked that the skb size correspond to something written in some
header, well, just speculating, I'm confused about.
- is that correct to have status.rate_idx filled by functions
b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that
compute those values reading the plcp?
Yes I think so. This seems to be the best way to do it.
After some thoughts I'm wondering how these fields could be wrong
since the PLCP is protected on its own by another checksum external to
MPDU. Probably the firmware keep also frames whose PLCP is wrong,
while b43_rx only check for FCS problems within the MPDU. Will
investigate.
When a frame is ok, values are
correct and mac80211 uses them without problems. If instead the frame
is not ok, then mac80211 can warn a lot of message because values are
out of range.
If the PLCP header is corrupt you're completely fucked anyway.
It is a basic and safe assumption that the PLCP header is correct.
But it shouldn't _crash_ if it's not correct. But I think it doesn't.
Well, I think that capturing noisy frames is interesting for all those
guys willing to use data for research purposes without buying a
network analyzer that basically do the same...
So if you crank up the flags to pass PLCP corrupted frames it's kind
of
expected that they are dropped somewhere in the driver, because we
cannot
trust the contents of the frame anyway.
How do we know the PLCP length field is still correct for a
corrupted PLCP?
So we don't even know if the frame would have the correct length.
Should not we parse these values when FCS is bad and
sanitize them if out of range so that dmesg does not get filled with
warnings?
These warnings were removed some time ago. Please update your kernel.
Uhm... I updated it before writing this mail to check about this
possibility but I believed these warns were still there
[taken from __ieee80211_rx() pulled from git yesterday night]
if (status-flag RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = 76))
return;
/* HT rates are not in the table - use the highest
legacy rate
* for now since other parts of mac80211 may not yet
be fully
* MCS aware. */
rate = sband-bitrates[sband-n_bitrates - 1];
} else {
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = sband-n_bitrates))
return;
rate = sband-bitrates[status-rate_idx];
}
Or probably there is another method to get those values,
e.g., the firmware can provide them reading from the radio instead of
computing them reading fields from the plcp?
I don't see why this is necessary and how it would be possible.
You are right, we have simply to trash real noise (frames whose plcp
was corrupted) so to avoid to decode the Microwave Owen as you were
Re: Capturing FCS error frames using b43 driver
On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote: On Wednesday 18 February 2009 00:07:56 Bo Han wrote: I think I am working on the first sanity check in the driver, but still cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD the only thing we need to do for the firmware? No. I suggest you don't touch that flag anyway and change the corresponding mac80211 filter flag. You most likely can do that through cfg80211/ nl80211/iw. It will take care to set the b43 flag. Michael is right, the new iw interface eases all this stuff. There are however a few points that should be discussed - why b43_rx(...) (in xmit.c) does not mark the status with RX_FLAG_FAILED_FCS_CRC when the firmware reports a B43_RX_MAC_FCSERR: IMHO this should be done to prevent mac80211 to be corrupted and crash the pc when a _very_ noisy frame arrives - is that correct to have status.rate_idx filled by functions b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that compute those values reading the plcp? When a frame is ok, values are correct and mac80211 uses them without problems. If instead the frame is not ok, then mac80211 can warn a lot of message because values are out of range. Should not we parse these values when FCS is bad and sanitize them if out of range so that dmesg does not get filled with warnings? Or probably there is another method to get those values, e.g., the firmware can provide them reading from the radio instead of computing them reading fields from the plcp? - I noticed that when in monitor mode and when set up to keep bad frames, the radiotap header is not reporting FCS wrong for malformed or corrupted frame as it should be, is that correct? Should not the radiotap header be built on the status filled by first the driver then mac80211? Cheers, -FG -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 2, 2009, at 4:23 AM, Larry Finger wrote: I was able to crash the 5.0 firmware again today after a 7 hour run This time I had the following patch applied: Finally I got my equipment, a rev 3 4306 Broadcom cardbus adapter, to crash too. What is strange is that during the weekend I did several tests and everything was fine. Today, instead, I brought both laptop and cardbus adapter into the lab and each time I begin to download even very small files, it crashes. This happens with both openfwwf and original Broadcom firmware. I tested another cardbus adapter (though I believe they are the same, both Belkin) and it crashes too. Switching back to internal mini-pci, instead, I have no problems. Unfortunately I do not observe any message from console, I set /proc/ sys/kernel/printk to log everything but the system simply hangs and I have to switch it off. The only difference between the lab and my home networks is that here (lab) we have several SSIDs broadcasted, I can clearly observe tens of APs on the same channel and a lot of background traffic. Note that the PC is rock solid, it never crashes in other conditions. The same situation appears with two cardbus adapters so I can't believe they are both broken and independently of the cardbus slot I plug the network adapter into. Has anyone knowledge about incompatibility between b43/bcm adapters and this kind of CardBus bridge (as reported by lspci) CardBus bridge: ENE Technology Inc CB-720/2/4 Cardbus Controller (rev 01) I always believed it was 32-bit (isn't it?) and I used it without problems for a long time with an Atheros controller so I believe it is not broken. Cheers -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote: On Sunday 01 February 2009 11:16:29 Michael Buesch wrote: If it's not an external condition, it could possibly also be a bit in the TXE or something like that. I'm not completely sure on that one. But external condition would be my first bet, as we have lots of other external conditions for other overflow conditions. For my understanding of what's going on with Larry's adapter, may I kindly ask you if the following picture is correct? I simply put a printk just at the top of op32_poke_tx and another in handle_irq_transmit_status. I injected as mush traffic as I can by sending UDP style frames through a raw socket to the wireless interface, I send ten thousands packets so to enter a regime condition: after the first hundreds packets are sent, I see from dmesg a op32_poke_tx line followed by a handle_irq_transmit_status line, these two couple of lines repeated thousands times. More interesting is what happens at the end when I stop sending packets on the raw socket: the kernel stops filling the queue, and in dmesg we can see only handle_irq_transmit_status lines corresponding to frames still in the tx fifo. The firmware is removing these last packets and for each of them it will send a IRQ after sending. It always turn out that the queue had 64 packets inside, I always see 64 consecutive lines about handle_irq_transmit_stats. Is this number (64) due to the definition #define B43_TXRING_SLOTS128 in dma.h? For what I understand a slot is used for tx header, the other for the actual packet, isn'it? So we have half of 128 slots for 64 packets. If this is correct, the condition observed by Larry could be due to some packets being lost during their travel in the fifo run by the dma system? It seems that the firmware is reporting status for not all packets that have been sent through the dma, but we know that the firmware always reports status _unless_ the mac ctl register is set to skip status reporting. Could we investigate on this or I'm completely wrong? Cheers, -Francesco ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote: On Sunday 01 February 2009 11:16:29 Michael Buesch wrote: If it's not an external condition, it could possibly also be a bit in the TXE or something like that. I'm not completely sure on that one. But external condition would be my first bet, as we have lots of other external conditions for other overflow conditions. Well, the handler that reports status to host waits for a couple of external conditions, looping until they are satisfied: we left that about crypto because all times we removed something about crypto everything went bad, even if it seemed useless, do not consider it now. The other condition, instead, is the same that is checked before sending a received frame to host through _dma_, isn't it strange? There is no conditioning instead that prevents the IRQ about tx status reporting to be raised once we entered the reporting handler, and we jump into it after each sending. So each time we enter the report status handler, the IRQ is raised. So I think that the conditions you are talking can only be those two I said here above, no other bit is checked, and your bet was right :) Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 5:19 PM, Larry Finger wrote: The problem also exists in the 5.0 firmware. My test this morning died within 10 minutes. This time, there were only two transmits queued. The cookies were 0x2048 and 0x204A. Larry I'm happier now... though this means very hard debugging. It would be great if you can crash the original firmware too ;-) If it happens tell us... Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 5:32 PM, Michael Buesch wrote: On Sunday 01 February 2009 17:26:26 Francesco Gringoli wrote: On Feb 1, 2009, at 5:19 PM, Larry Finger wrote: The problem also exists in the 5.0 firmware. My test this morning died within 10 minutes. This time, there were only two transmits queued. The cookies were 0x2048 and 0x204A. Larry I'm happier now... though this means very hard debugging. It would be great if you can crash the original firmware too ;-) If it happens tell us... Don't you think this is a bit unlikely? We're using the proprietary firmware since, well,... ever? This particular version is in use since about a year. We didn't have a single report of this. In fact, I was joking! However if it happens... Jokes apart, I must reproduce this condition to debug it. Larry, would you mind loading up a modified firmware with a small kernel patch to report a cookie miss without crashing the system? Cheers, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 6:10 PM, Larry Finger wrote: Francesco Gringoli wrote: In fact, I was joking! However if it happens... Jokes apart, I must reproduce this condition to debug it. Larry, would you mind loading up a modified firmware with a small kernel patch to report a cookie miss without crashing the system? I don't mind. Just to clarify your question. Will you be sending me both new firmware and a kernel patch? Many thanks. I'm preparing them, I will send them ASAP. BTW, I realized I missed an earlier question of yours. My BCM4318 is CardBus, i.e. 32 bit. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 31, 2009, at 7:54 AM, Larry Finger wrote: Francesco, I changed the dma.c code to WARN_ON rather than BUG_ON and also dump the cookie for the erring case. Of course, the system no longer crashes, nor even stops on the first error. I have no idea how many errors occurred before I got it stopped, but the cookies for the first few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, 0x2050, and 0x2052. When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and obtained: [cut] Larry, many thanks for your help in debugging. However I can't reproduce that error. I tried all this afternoon with a 4306rev3 on a CardBus board but all efforts to freeze the PC were useless. I checked again the difference between r5.0 and r5.1 but it is only 10 lines... so easy to debug that I'm pretty sure that error is not due to changes into header offsets. Is there any way for me to me to freeze the interface when the first error occurs without inducing a kernel panic? I don't understand completely your question: if you need to stop the firmware without having its memory corrupted we can add a semaphore just after the WARN_ON into shm so that next loop after state_machine_start we enter an infinite loop. However this would happen after hundreds cycles. Tell me if we can helping adding debug blocks into the firmware. What kind of PC are you testing your CardBus adapter? Is that a 32bit or 16bit? Cheers, -FG Larry --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. What am I missing? Many thanks, Cheers, -FG What looks strange to me is that, if the error is somewhere in the tx_header definition, every transmission will result in an error from the b43_dma_handle_txstatus. If a field is not in the correct position, it is always wrong: it can't be sometimes right and sometimes wrong, don't you agree? I had similar problem beacause of the wrong header offsets definitions, but that made every transmission generate a BUG report... I don't understand how it is possible that almost always things went fine and sometimes report status was not correct... Well, you should probably patch the driver to print the cookie when the WARN_ON happens and reproduce. Please Michael, if you can, can you please check shm.inc header definition? Not yet. Maybe later. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Feb 1, 2009, at 12:49 AM, Michael Buesch wrote: On Sunday 01 February 2009 00:47:35 Michael Buesch wrote: On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: I think that's rather unlikely, however. The DMA code is basically unchanged for months and especially the slot handling hasn't changed in years. Yes, but I didn't mean that the code has some bug. Let's say, for example, that all the DMA slots were filled; when the firmware will try to report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? No. TX status isn't passed through DMA in =rev5 cores. It's passed through MMIO registers which access an internal hardware queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. The tx-status-queue-full condition most likely is an external condition in the firmware. Don't ask me which one, however. Ok, this could be a problem. Will check next days how to solve. I suppose now that the length of that report_tx_status queue is very device dependent as mine can grow it more than one hundred elements and status continues to be correctly reported. Cheers, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
opensource firmware now accept version 410 frames
Hello, we made a few modifications to the opensource firmware code and now it accepts frame encoded as version 410 layout. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
info about 4311 board running ucode13
Larry, could you please be so kind and check if this is the 4311 board you have? I found it on ebay and I would like to buy the correct one (hoping that the seller put the correct photo... :-) ) http://www.ing.unibs.it/openfwwf/private/hp-4311.jpg Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 29, 2009, at 6:48 PM, Larry Finger wrote: Francesco, Opensource firmware 5.1 works with my BCM4318; however, under heavy load with a ping running in one window and 10 second bursts of tcpperf transmissions in another, the kernel (2.6.29-rc2-wl) panicked by hitting the BUG at drivers/.../b43/dma.c:1386, which is in routine b43_dma_handle_txstatus. The specific condition is !meta-skb. No other messages made it to the log. I will investigate the kind of debugging aids that Michael mentioned and send more info when available. Larry Larry, many thanks, I will investigate: probably we missed something when switching from 5.0 to 5.1, sorry. By the way, have you ever tried a similar test with firmware 5.0? Hope yes and everything went fine :-) Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 30, 2009, at 12:09 AM, Larry Finger wrote: Francesco Gringoli wrote: - have you applied any recent patch to the kernel (we too are using 2.6.29-rc2-wl), so that your kernel can behave differently than ours? - are you sure you are using the correct initvals files? Those we put today on the website? - have you replaced _all_ the files, including shm.inc etc? Here we redefined the txheader layout and moved the cookie address - are you modprobing by setting qos=0? - is your card a PCCARD or PCI? The only patch I had applied to 2.6.29-rc2-wl was to have b43 look for opensource firmware before the proprietary version. The complete set I still did not have time to integrate this patch, I will try it tomorrow. of files from the openfwwf-5.1.tar.gz were applied and the firmware built from them. I am modprobing with qos=0 and nohwcrypto=1. I have a Perfect. PCCARD format. It is labeled as a Linksys WPC54G, ver. 3. Ah... well, although Lorenzo did lot of this work using his 4318 PCCARD branded Belkin, I observed very bizarre behavior when using PCCARD in the past, independently of the firmware type (also with the original Broadcom one), to such point that I gave up and switched to PCI and PCI-express only testbeds. However I will give a try tomorrow, I'm curious now to see what happens with new kernel + r5.1 + PCCARD. [cut] when you want, in this case just after the SIFS and only for frames sent to one not existing MAC addresses, so that no ack is sent by no one). Actual packets transmission verified by sniffing the channel by using another Broadcom card Your tests are a lot more rigorous than mine. I'll repeat my tests. Larry Many thanks, Cheers -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
On Jan 30, 2009, at 12:09 AM, Larry Finger wrote: Francesco Gringoli wrote: we just finished a couple of stressing tests and everything went fine, kernel did not complain about anything, below is attached the tests description. Just a few questions - have you applied any recent patch to the kernel (we too are using 2.6.29-rc2-wl), so that your kernel can behave differently than ours? - are you sure you are using the correct initvals files? Those we put today on the website? - have you replaced _all_ the files, including shm.inc etc? Here we redefined the txheader layout and moved the cookie address - are you modprobing by setting qos=0? - is your card a PCCARD or PCI? The only patch I had applied to 2.6.29-rc2-wl was to have b43 look for opensource firmware before the proprietary version. The complete set of files from the openfwwf-5.1.tar.gz were applied and the firmware built from them. I am modprobing with qos=0 and nohwcrypto=1. I have a PCCARD format. It is labeled as a Linksys WPC54G, ver. 3. Larry, just one more question: if you have time to test again r5.1, not a stress test, a wget is enough, could you please report info about rx and tx_ring usages? Those lines like the following: [219861.208427] b43-phy222 debug: DMA-32 rx_ring: Used slots 8/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [219861.216070] b43-phy222 debug: DMA-32 tx_ring_AC_BE: Used slots 128/128, Failed frames 1600/3398448 = 0.0%, Average tries 1.19 Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:45 PM, Larry Finger wrote: Francesco Gringoli wrote: Damn... that would be a very hard writing We do not have any 4311/2 board: at first glance there are more condition registers whose meaning we do not know. Very different hardware, didn't know. Thank you for the feedback. By the way: is that device inside an AP? If yes what? if not which brand has the board on? I can look around. Mine is on a mini-PCIe card in a laptop. The part has an HP Part #441090-001, but I expect there are Dell equivalents that are cheaper. I don't know about an AP. Larry Larry, could you please be so kind to try the opensource firmware on that 4311/2 card by renaming it ucode13 and report what happens? I suggest to try monitor mode without associating first. Thanks a lot. -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
integration of opensource firmware with b43 kernel driver
Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 I was considering the suggestions you all gave me a few days ago and other questions related to the possible integration of this firmware into the kernel, and I came to these conclusions/questions (please forgive me for this long message :-) ) - change the name of the initvals for the opensource firmware: this seems a little bit complicated as now the decision about the initval- files' names and the detection of the firmware type are respectively based on the phy type and on the firmware date. This means that initval-files' names can be determine as soon as the hardware type has been probed, while the firmware needs to be started before the kernel can determine if it is opensource or not: at this time, however, the initvals have already been uploaded. What can we do? - detection of the opensource firmware capabilities: are you really sure we cannot use a shm location that the bcm proprietary firmware uses for some other purpose? Once, in fact, the kernel has determined that the firmware is opensource it can also use a given location in a different manner than it would do for a proprietary firmware. However this is not a problem at all :-) as we can use one location in the high shm-memory area, let's say 0xb00, just choose one. - what to do with rts procedure: we can implement this feature easily but I'm not sure about the value it can add to people (the majority of users?) that use the bcm board in station mode. This is different for those who run a bcm card in AP mode, but we can clearly discourage them to run this firmware in AP mode if not sure about rts usage by stations. However, we put this task in the todo list. - tx header layout: the opensource firmware is now using the old memory layout in the tx header (351). Do you think switching to 410 format is mandatory now or we can concentrate on the other tasks? - I would like to start considering N-phy on the firmware side. I have a late 2008 MacBook Pro and I'm not sure if beginning this work on this platform is a waste of time or not as Apple could have asked Broadcom a customized chipset. Should I start or is it better if I buy a N-phy pci board for my x86 box? Thank you for your time. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 7:02 PM, Michael Buesch wrote: On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote: Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 I don't think it has enough testing, yet. Sure, it seems to be stable on _our_ boards but I can't tell if it shows the same behavior on other hardware revisions. I was considering the suggestions you all gave me a few days ago and other questions related to the possible integration of this firmware into the kernel, and I came to these conclusions/questions (please forgive me for this long message :-) ) I don't think we want to have the firmware in the kernel. Instead distributions should simply ship the firmware in a package. That's not our business. I agree with you, distributions could easily package the firmware and distribute it to users when it will be stable, I was just wondering about. - change the name of the initvals for the opensource firmware: this Why? [cut] initvals have already been uploaded. What can we do? Nothing. Why do we need to have different names? Well, I was only considering a question raised by John, we can surely maintain these names. - detection of the opensource firmware capabilities: are you really sure we cannot use a shm location that the bcm proprietary firmware uses for some other purpose? Yes, well. You're not intermixing an earlier discussion into this, where you didn't indicate opensource capabilities to the kernel. If you indicate OS capabilities, you can use whatever offset you want, of course. Excellent. We will modify the firmware accordingly and encode the options. - what to do with rts procedure: we can implement this feature easily but I'm not sure about the value it can add to people (the majority of users?) that use the bcm board in station mode. This is different for those who run a bcm card in AP mode, but we can clearly discourage them to run this firmware in AP mode if not sure about rts usage by stations. However, we put this task in the todo list. RTS/CTS is not specific to AP mode. It's used on any station in the BSS. See IEEE 802.11 specs. Yes, in fact we put this task in the todo list. - tx header layout: the opensource firmware is now using the old memory layout in the tx header (351). Do you think switching to 410 format is mandatory now or we can concentrate on the other tasks? Yes, the old format is deprecated and will be removed soon. Ok, first task in the todo list! - I would like to start considering N-phy on the firmware side. I have a late 2008 MacBook Pro and I'm not sure if beginning this work on this platform is a waste of time or not as Apple could have asked Broadcom a customized chipset. Should I start or is it better if I buy a N-phy pci board for my x86 box? A little bit of b43-asm work is still needed for this core. There are a few FIXMEs in the code. Not sure, maybe there's more to do. I didn't try that, yet. Before you start, you'll have to verify whether the assembler works correctly. Same for the disassembler. Ok, thanks for the hint. I will check, Cheers, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 7:01 PM, Larry Finger wrote: Francesco Gringoli wrote: Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 As a point of clarification, I think this is restricted to the 4311/1 as the 4311/2 uses ucode13, not ucode5. If you need a tester for an open-source version of the 13 firmware, I'm available. Damn... that would be a very hard writing We do not have any 4311/2 board: at first glance there are more condition registers whose meaning we do not know. Very different hardware, didn't know. Thank you for the feedback. By the way: is that device inside an AP? If yes what? if not which brand has the board on? I can look around. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:33 PM, Michael Buesch wrote: On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote: Nothing. Why do we need to have different names? Well, I was only considering a question raised by John, we can surely maintain these names. I guess I missed that. What was the question? Note that proprietary and open firmwares are in separate directories, so I don't see why we should rename them. Renaming firmware is a huge pain. We did it several times in the past and I really want to avoid it. It creates a major confusion for users for some months. Sorry sorry sorry and sorry again... it was a Larry question, not John's... pardon me -- Is using the Broadcom names for the firmware the best course of -- action? What if the opensource firmware files were named something -- like os-ucode5.fw, etc. and b43 were coded to check for those files -- first? It would then fall back to the standard firmware if the -- opensource version is not found. However, it's not a problem maintaining these names. - detection of the opensource firmware capabilities: are you really sure we cannot use a shm location that the bcm proprietary firmware uses for some other purpose? Yes, well. You're not intermixing an earlier discussion into this, where you didn't indicate opensource capabilities to the kernel. If you indicate OS capabilities, you can use whatever offset you want, of course. Excellent. We will modify the firmware accordingly and encode the options. Thanks. Would be nice if you could also do the corresponding driver patch. Ok, it should be simple. - tx header layout: the opensource firmware is now using the old memory layout in the tx header (351). Do you think switching to 410 format is mandatory now or we can concentrate on the other tasks? Yes, the old format is deprecated and will be removed soon. Ok, first task in the todo list! Well, doesn't need to the the first one. Just note that support for this is scheduled to be removed in summer 2008. So if any problems show up (broadcom releases yet another API, for example), I will immediately remove it. Well, it's the first because it's the easiest :-) Ok, thanks for the hint. I will check, There are a few things we're not yet sure about. For example the operand for the GPR number got an additional bit. But we're not sure if the real number of GPRs also was doubled in the hardware. There are a few FIXMEs in the code for this... I think this simply has to be tested by trial and error. Thanks, I will surely check this. Cheers, -FG -- Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:37 PM, Michael Buesch wrote: On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote: On Jan 23, 2009, at 7:01 PM, Larry Finger wrote: Francesco Gringoli wrote: Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 As a point of clarification, I think this is restricted to the 4311/1 as the 4311/2 uses ucode13, not ucode5. If you need a tester for an open-source version of the 13 firmware, I'm available. Damn... that would be a very hard writing We do not have any 4311/2 board: at first glance there are more condition registers whose meaning we do not know. Very different hardware, didn't know. Thank you for the feedback. Well, if you didn't notice it already, there are a zillion different flavors of the broadcom wireless chip out there. So if you buy a random device, you're almost guaranteed that you don't have that flavor already. ;) Ehm... I begin to notice now... we were so engaged in understanding the tx state machine that we lost this _huge_ detail(!). They (Broadcom) should have plenty of engineers to design so many different chipsets. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 6:44 PM, Brian J. Murrell wrote: On Fri, 2009-01-23 at 18:36 +0100, Francesco Gringoli wrote: Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. Did you try pushing it hard? i.e. doing a nice big bulk transfer through it? Did it reach decent speeds without pegging the CPU with softirqs? Can you give details on which kernel(s) and how you built/configured the router firmware(s)? Well, I just tested a 500Mbytes bulk transfer and I got a mean throughput of about 5.5Mbit/s, it was a simple infinite wget loop so we can have some slowness due to TCP. However no errors were logged to syslog and the AP is still there, it didn't complain about anything. I built kamikaze yesterday image (r14144), kernel 2.6.25.17, I used the AP as a station joined to another AP without encryption. By the way, we did thousands of tests with x86 and we came to the conclusion that there is no performance (throughput) difference if compared to the standard proprietary firmware. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom driver in Android
On Jan 22, 2009, at 10:51 AM, Thomas Ilnseher wrote: Am Donnerstag, den 22.01.2009, 10:26 +0100 schrieb Holger Schurig: Just found this in the Android's repository and think maybe this info can be useful for someone in this list: http://android.git.kernel.org/?p=platform/system/wlan/broadcom .git;a=summary .. and it's even GPL. :-) but it's for an broadcom chip with built-in arm7tdmi cpu, and built-in firmware So doesn't help too much for normal broadcom cards ... Though there are handlers in the code to download firmware somewhere (they end with _download_firmware), so should one believe that a firmware image could be provided? I didn't find any in the android git repository. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
Hello everyone, we just made available a new opensource firmware version, download at http://www.ing.unibs.it/openfwwf New features: - initvals source code added, initvals files are encoded by make process - firmware is now recognized as opensource, though still as version 351 (old format). Firmware's date switched to - watchdog implemented Tested with kernel 2.6.29-rc2-wl. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Jan 15, 2009, at 4:59 PM, Larry Finger wrote: Michael Buesch wrote: Yes, please introduce a feature-bitfield at some location in SHM that's unused by the proprietary firmware. This bitfields would contain a bit for QoS and a bit for hwcrypto. Also change your firmware so the driver detects it as open-source firmware. I think that's done by writing 0x to the date/time field in SHM. I don't quite remember, but it's something like that. Note that this might mean that the firmware watchdog in the driver will trigger, as that's enabled by the open-source-firmware-flag. We might want to temporarly disable the watchdog in the driver for the time being. I like the idea of encoding the capabilities in the firmware as it would be a self-documenting method as the firmware evolves. Is using the Broadcom names for the firmware the best course of action? What if the opensource firmware files were named something like os-ucode5.fw, etc. and b43 were coded to check for those files first? It would then fall back to the standard firmware if the opensource version is not found. Larry It could be interesting to also not separate the initvalues in two different files, everything could be coded in a single file. Never understood why original init values are split in two files. Michael: SHM(0x0014) (16bit) is not used by the open source firmware, I know the b43 reads core revision from SHM(0x0016). Normally SHM(0x0014) is set to zero. We can put fw capabilities here (0x0014), e.g.: - bit 0: [0 state that encryption should be handled by b43] - bit 1: [0 state that qos is not supported] We can prepare a firmware image with such feature + watchdog. Posting ASAP with new initvals (less values). A question: is the standard kernel aware that date set to indicates an opensource firmware or some define should be activated on compilation? Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LED on BCM4311 on Acer Extensa 5220
On Jan 15, 2009, at 4:35 AM, _...@list.ru wrote: (Previous message failed) The Wi-Fi status LED on Acer Extensa 5220 works incorrectly. When using b43, it is turned on only if radio is disabled. When using ndiswrapper, it is blinking when disconnected, on when connected and rapidly flashes when information is being sent or received. When /sys/class/leds/b43-phy0::radio/brightness is set to 0, the LED is turned on. When it is 1 to 255, the LED is off. vi-notebook:/sys/class/leds/b43-phy0::radio# cat trigger none ide-disk rfkill0 ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full mmc0 phy0rx phy0tx phy0assoc phy0radio [rfkill4] [cut] I was wondering if offloading led handling to firmware could be a positive feature or it is better practice to handle blinking on the host side. Really I do not know: however if needed, the feature can be easily added. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Jan 12, 2009, at 4:39 PM, John W. Linville wrote: On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote: Hello everybody, today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with Broadcom 4306 chipset: BCM94306 802.11g (rev 03) PHY: Analog 2, Type 2, Revision 2 Radio: Manuf 0x17F, Version 0x2050, Revision 2 I did some tests and everything seems to work fine. I remember, once again, that OpenFWWF needs v480 initvals to work properly, and was tested on 2.6.27-rc5 kernel. Any chance on getting a set of initvals packaged with the open source firmware? That would allow distros like Fedora to package this... John -- John W. Linville Linux should be at the core linvi...@tuxdriver.comof your literate lifestyle. Yes, we have it now. Still testing as several values can be cut out. Posting ASAP. Cheers. -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
opensource firmware
Hello folks, we have been involved in the past few months in testing modifications to the standard 802.11 MAC for research purposes. During this time we did some tests with Broadcom 802.11b/g boards and we wrote down a simple 802.11 compliant firmware that we used as a starting point for the modified MAC algorithms. Although the base firmware is not fully 802.11 compliant, e.g., it does not support RTS/CTS procedure or QoS, we believe that someone could be interested in testing it. The firmware does not require the kernel to be modified and it uses the same shared memory layout and global registers usage of the original stuff from broadcom to ease loading by the b43 driver (and ease our writing...). We wrote it to make the b43 driver recognize it as Broadcom version 5 firmware: it still uses the original initval files of that version of the Broadcom's firmware, we do not include them as usual users have to extract these files following the b43 installation instructions. Lorenzo and I tested this firmware only on 4306 and 4318 hardware (pci and minipci, pc-card based architectures seem to have problems), and we did simple tests on the integrated board of a Linksys WRT54GL, so we are quite sure it runs on 4306, 4318 and 4320 cards. We did all the works on kernel 2.6.27-rc5-wl. The firmware along with the instructions to build it from the assembly code using the tools developed by the b43 community can be found here http://www.ing.unibs.it/openfwwf In the firmware website you can find more information about the fw algorithm, its interaction with Broadcom hardware and other information that we discovered as we were writing it. We would like to underline that this work would have not been possible without the instruments already developed by the b43 community (assembler/disassembler), hardware specifications (sipsolution's website), the opensource test firmware written by Michael Buesch and useful talks with those guys (b43 developers), which we deeply acknowledge. As we used several definition files written by Michael for its firmware and we have prepared a source tar file that includes them, we kindly ask Michael if this could be a problem. Finally we stress that this is a TEST firmware and some stuff needs to be fixed (e.g. RTS/CTS and QoS), we have been using it as a starting point to implement other MAC algorithms for research purposes: if someone is interested in this kind of work and would like to share ideas also on research topics, please let us know. Cheers, Francesco Gringoli Lorenzo Nava ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Hi Michael, we are collecting every kind of material about Broadcom board, too. Could you please point out the document with such specifications? I confirm what Lorenzo wrote: there are 32 bytes for queue. If you leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board takes (quite) exclusive control of the channel as gap is always set to zero. Cheers, -FG On Sep 10, 2008, at 2:58 PM, Michael Buesch wrote: On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote: Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? The specifications says there are 22 (decimal) entries. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43: out-of-standard behavior
Hello everybody,
we found a strange behavior problem with the b43 driver. We begin
investigating this when doing some access tests with several boards:
we discovered that the Broadcom boards usually acquire the channel
usage with higher priority when the b43 driver is used as respect to
other vendor boards.
After investigating we saw that the intra-queue contention procedure
is carried out by the firmware which stores information, such as AIFS
and current backoffs for each queue, inside the shared memory. The
AIFS for each queue is used to compute the initial backoff so that
internal contention usually gives more priority to VO queue (smallest
AIFS) and less to background (biggest AIFS). AIFS parameters are
initialized by the driver which is told to use a 22 words long
structures. The firmware instead use 16 words structures: this means
that AIFS parameters initialized by the driver do not match the
corresponding values read by the firmware. We saw that the firmware
reads (2,0,0,0) instead of (2,2,3,7) which results in very short
backoff procedures.
Has anyone noticed similar behavior? For the sake of clarity, I'm
referring to latest (30 minutes ago) version of wireless-git and
broadcom-wl-4.150.10.5 driver version. I verified that all ucode5.s,
ucode9.s, ucode11.s, ucode13.s and ucode14.s firmwares use 16 words
structures, and the driver instead still uses 22 words long
structures. Probably the attached patch sorts out the problem.
I also noticed that the specs say that these structures are 16 words:
could not someone read 16 as 0x16 that finally became 0x16 = 22?
Cheers,
FG
--- b43.h.old 2008-09-10 21:12:59.0 +0200
+++ b43.h 2008-09-10 21:13:09.0 +0200
@@ -569,7 +569,7 @@
#define B43_QOS_VOICE B43_QOS_PARAMS(3)
/* QOS parameter hardware data structure offsets. */
-#define B43_NR_QOSPARAMS 22
+#define B43_NR_QOSPARAMS 16
enum {
B43_QOSPARAM_TXOP = 0,
B43_QOSPARAM_CWMIN,
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4308 rev 3 owner, willing to help (want to make an access point)
Just a question (for Francis): how does the AP work? Have you tried very stressing tests with traffic crossing the AP? We do have problems when the channel is saturated, it seems that the BCM device acting as AP stops sending beacons and the BSS goes down, we need to reconfigure everything when this happens (I mean, stop and restart hostapd and reset ifaces on STAs). The configuration we are trying is built exclusively on BCM+b43 devices running wireless git, one is configured as AP using the patch from Johannes Berg. I remember a post (from Johannes) where he stated that there are still problems with beaconing. Is this still true? Regards, FG On May 1, 2008, at 11:05 PM, Francis Galiegue wrote: 2008/5/1 Francis Galiegue [EMAIL PROTECTED]: 2008/5/1 Johannes Berg [EMAIL PROTECTED]: unencrypted AP -- success; [WPA] -- segfault http://johannes.sipsolutions.net/patches/kernel/all/2008-05-01-00:32/023-mac80211-fix-debugfs-key.patch Better, but not there yet... At least now it doesn't segfault. I ran again hostapd with -d this time. Here is what I get... [...] Well now it runs! It appears that hostapd definitely does NOT like bridge interfaces. There is a bridge_interface option though, but the config file says it has no effect apart from using it with the ath and hostap drivers... -- Francis Galiegue, [EMAIL PROTECTED] It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries (Stéphane Faroult, in The Art of SQL, ISBN 0-596-00894-5) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Microcode reverse engineering
Hi Johannes, I'm currently involved in a project that requires to change a few mac timings and other stuff: this is the reason I'm very interested in decoding the Broadcom firmware, it could be a good development platform without having to buy code and sign NDAs. I spent a couple of day trying to collect all documents about what Broadcom has acquired before 1999 and that could have been implemented into AirForce Mac Processors. I didn't find anything that was explicitly saying we are using this core. I have now a few conjectures about the library used to build the chip, let's say a few candidate: - E14 firepath - Trimedia CPU64 - A kind of ARM core mixed with a FPGA lib I discovered some patents talking about wifi network and the CPUs of above. Do you have any idea? I also discovered this url http://www.arm.com/iqonline/news/ partnernews/15399.html check it out for future drivers. And I would very be pleased to know how did you pointed out the meaning of the opcode in the website. Thank you very much for your time, cheers, FG % Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 % ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Microcode reverse engineering
Hi Michael, It could also be the case that the opcodes on the website aren't opcodes to a real CPU, Broadcom calls this a Programmable State Machine. But what is this all about? Why do you care what type of CPU this is? Does this matter _at_ _all_? I mean, we know all opcodes of the device and we have a _complete_ disassembler and assembler. http://git.bu3sch.de/git/b43-tools.git Can't you put this on the web site? Only a small link... What do you want more? The only thing we don't completely understand are the various device registers and device status codes (external jumps) used. But that has nothing to do with the type of the CPU used. Yes, you are right. I will now use the tool to better understand the device. Thank you very much. You did a great job! FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: microcode reverse engineering
Hi Johannes, I found the 802.11 section on your website this morning, I don't know why I didn't find it before. That's very interesting and you did an impressive work!! I don't understand when you say that you're not interested in r4 microcode or higher because it seems that there are two different microcode description and it seems that the boundary is between (r3,r4) and (r5), is that correct? From these links I can find http://bcm-v4.sipsolutions.net/802.11/Microcode - core revision 5. Is that r5? and http://bcm-v4.sipsolutions.net/802.11/OldMicrocode - core revision 4 and lower. Is that r3 and r4? Are they the same? Have you tried to write your own mac to see if it works? Thank you very much, FG On Dec 3, 2007, at 11:38, Johannes Berg wrote: On Sun, 2007-12-02 at 15:55 +0100, Francesco Gringoli wrote: Hi Johannes, I read the interesting note you wrote on September about r4 ucode reverse engineering. Have you new results since then? http://bcm-v4.sipsolutions.net/802.11/Microcode has a link to the old format too. I'm not particularly interested in the r4 format. Did you understand what kind of core is bcm4318 based on? From broadcom website it should be a MIPS32 core (check http://www.broadcom.com/ products/Wireless-LAN/802.11-Wireless-LAN-Solutions they say that The AirForce family of network processors features MIPS32 processor...(cut)). It's interesting that you found out a 6 bit prefix, like in MIPS! Nope, I don't think it's MIPS. I think AirForce network processor refers to the whole integrated thing that can be used as a full-mac chipset or a whole access point etc. Before reading your post I came to these conclusions - all odd words begins with zero (or a couple of them, this depends on the firmware version). This led me to think to 8 byte wide instructions. Unfortunately both mips32 and mips64 use 32bit wide instructions. No mips? - odd words are control codes to check even words correctness during firmware upload: unfortunately there are a lot of even words repeated throughout the code with different paired odd words. Did you try to change randomly some values and see what happens? - disassembling the code after having cut out odd words leads to MIPS assembly without ret instructions. There is no code too to handle IRQ. You want to read the above link and what is linked from it. I also tried to change endianness but didn't find anything more interesting. By the way, do you think that a complete reverse engineering could give us a platform to test new MAC methodologies? E.g. do you think it would be possible to change timings or medium control? Yes. johannes % Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli % ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
microcode reverse engineering
Hi Johannes, I read the interesting note you wrote on September about r4 ucode reverse engineering. Have you new results since then? Did you understand what kind of core is bcm4318 based on? From broadcom website it should be a MIPS32 core (check http://www.broadcom.com/ products/Wireless-LAN/802.11-Wireless-LAN-Solutions they say that The AirForce family of network processors features MIPS32 processor...(cut)). It's interesting that you found out a 6 bit prefix, like in MIPS! Before reading your post I came to these conclusions - all odd words begins with zero (or a couple of them, this depends on the firmware version). This led me to think to 8 byte wide instructions. Unfortunately both mips32 and mips64 use 32bit wide instructions. No mips? - odd words are control codes to check even words correctness during firmware upload: unfortunately there are a lot of even words repeated throughout the code with different paired odd words. Did you try to change randomly some values and see what happens? - disassembling the code after having cut out odd words leads to MIPS assembly without ret instructions. There is no code too to handle IRQ. I also tried to change endianness but didn't find anything more interesting. By the way, do you think that a complete reverse engineering could give us a platform to test new MAC methodologies? E.g. do you think it would be possible to change timings or medium control? Cheers, FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
