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: DMA queue overflow
On Jul 31, 2009, at 1:00 AM, Larry Finger wrote: > Francesco Gringoli wrote: >> 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. > > I saw one on a web site that only has 3 power-regulator chips. It > couldn't possible do anything but just transfer the signals in a > mechanical fashion. > > Larry > > Hi Larry, I did some testing with my old notebook and the PCCARD boards. The mini-pci-e boards from Hong Kong are still missing, I begin to suspect that I should buy others from some other vendor. The two boards are the same, Belkin F5D7011: they are reported as being functional with b43. Unfortunately they have the same behavior, they crash the pc also with the proprietary firmware. Could this bug due to the Cardbus Controller? I'm using the kernel from wireless- testing, downloaded yesterday (2.6.31-rc5-wl). This is the lspci output 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 03) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to- PCI bridge (AGP) 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 14) 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller 00:02.3 FireWire (IEEE 1394): Silicon Integrated Systems [SiS] FireWire Controller 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0) 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 00:0a.0 CardBus bridge: ENE Technology Inc CB-720/2/4 Cardbus Controller (rev 01) 00:0a.1 CardBus bridge: ENE Technology Inc CB-720/2/4 Cardbus Controller (rev 01) 00:0a.2 FLASH memory: ENE Technology Inc CB710 Memory Card Reader Controller 00:0c.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) 00:0d.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 01) 02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) The PCCARD board is the last line, the other board from broadcom is an internal minipci. This is the output of b43 in dmesg (cut) [ 179.987899] b43-phy1: Broadcom 4306 WLAN found (core revision 5) [ 180.025070] b43-phy1 debug: Found PHY: Analog 2, Type 2, Revision 2 [ 180.025096] b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 I will try to access through the serial console to check if some message is reported before crash. 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: [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: [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: > 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- > SERR- 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
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 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 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
Re: Improved opensource firmware
On Jul 24, 2009, at 11:43 AM, Michael Buesch wrote: > On Friday 24 July 2009 02:13:38 Francesco Gringoli wrote: >> >> Hello Michael, >> >> yes, you are right. I was referring to something like mov 0x, >> HOST_MEM[random]. >> >> Jokes apart, I really didn't think about this possibility but I >> believe your idea is correct. I originally thought, reading the >> specs, >> that the dma controller can be configured not only with the base >> address but also with a "Descriptor Stop Index", and I thought this >> was an upper limit to the memory it can use, beyond that the >> controller would have turned down to the beginning of the ring. >> Instead I see from the kernel code that there is not such kind of >> limit, is it right? Is it the kernel responsible of taking down the >> controller to the first slot when the dma reserved memory is >> exhausted >> (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but >> I'm missing some details. > > Well it depends on the architecture to which places the DMA > controller can write. > On i386 it can write pretty much anywhere. On x86_64 it can probably > only write to mapped areas due to the IOMMU. > > The engine is supposed to wrap reading/writing at the descriptor > table end marker > and should stop at the index marker. As I wrote to Larry I decided to buy that kind of card. When I get it I will try to reproduce that problem and catch the bug. Thanks for clarifying the DMA. >>>> I suppose that the issue on pccard32 >>>> hardware is not yet solved. >>> >>> Which issue? >> The one we are talking about, reported by Larry for some pccard32 >> boards where the opensource firmware crashes. We did several testing >> with a few 4306 pccard32s the first time Larry reported the problem >> but unfortunately that hardware has different problems and crashes >> also with the original firmware. > > Ok. I'd like to see some oopses with proprietary firmware. I will have to send you the laptop and the cards (happens with both cards I have of that kind) because there is nothing written on display, it simply gets freeze. I also tried to enable the debug features such as magic system request keys to print something but they do not work. However the board is different than the one Larry reported the problem and in my case it can be something due to some hardware incompatibility. >>> This crash does _not_ happen with proprietary firmware. >>> The only way dev->fw.rev could crash is by dev being NULL. >> Got it! > > Ok, NULL was a typo. I meant "invalid" instead. > > -- 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: Improved opensource firmware
On Jul 24, 2009, at 3:44 AM, Larry Finger wrote: > Francesco Gringoli wrote: >>> >>> >> Hi Larry, >> >> Last time (it was February I believe) I didn't buy anything because I >> was involved in other projects. So again I ask you if I can place an >> order for this item >> >> http://cgi.ebay.com/HP-PCI-E-Broadcom-4312-wifi-card-generation-of-4311_W0QQitemZ320388697319QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item4a98a78ce7&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1234%7C293%3A1%7C294%3A50#ht_2507wt_1012 > > You must be careful with BCM4312 units as some of them have rev 5 > cores, but some have LP PHYs. The correct HP Part Number is > 459263-001. The one you looked at is 459263-002, which has the LP PHY. > One other criterion is the -001 is an 802.11abg unit, whereas the -002 > is 802.11bg. > > The one in the listing below is the correct model. Unfortunately, it > is in Malaysia and the shipping will be high. > http://cgi.ebay.com.my/ws/eBayISAPI.dll?ViewItem&item=150358107902 > > If there is a problem finding one at a reasonable price, I would be > willing to ship mine to you. Hi Larry, Don't matter, I just bought a couple of 4312 rev1 from the sellers you pointed out (just in case one adapter was broken...) I will start testing as soon as I get them. > > > I got the dump from a second error from my PCIe card. It hit the > BUG_ON(!meta->skb) in b43_dma_handle_txstatus() (Line 1414 of > drivers/net/wireless/b43/dma.c). In the first one I reported, > meta->skb was not NULL, and it crashed during the > unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1). I think having the hardware is mandatory because we are now doing stress testing using a number of 4318s and also several linksys WRT54GL and we can never observe a crash. After the last improvement the boards get never halted. So there should be something that must be handled differently on 4312/001. We will discover... Many thanks for your help, 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: Improved opensource firmware
On Jul 23, 2009, at 11:29 PM, Michael Buesch wrote: > On Thursday 23 July 2009 17:18:24 Francesco Gringoli wrote: >> On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: >> >>> On Thursday 23 July 2009 04:05:17 Larry Finger wrote: >>>> Francesco Gringoli wrote: >>>>> 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. >>>> >>>> Francesco, >>>> >>>> The system ran about 30 minutes, then crashed. I missed the first >>>> oops, but caught a kernel panic with formal traceback on my i386 >>>> system: >>>> >>>> b43_dma_handle_txstatus + 0x1ee/0x2fa >>>> b43_handle_txstatus + 0x45/0x52 >>>> >>>> The call in b43_dma_handle_status is at line 1405: >>>> >>>> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, >>>>1); >>>> >>>> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to >>>> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the >>>> oops. >>> >>> How is that possible? Is the firmware clobbering random memory? >> >> I don't think that the value was modified by the firmware. It cannot >> poke values into host memory ;-) > > Oh yes it can. It has a DMA engine. Hello Michael, yes, you are right. I was referring to something like mov 0x, HOST_MEM[random]. Jokes apart, I really didn't think about this possibility but I believe your idea is correct. I originally thought, reading the specs, that the dma controller can be configured not only with the base address but also with a "Descriptor Stop Index", and I thought this was an upper limit to the memory it can use, beyond that the controller would have turned down to the beginning of the ring. Instead I see from the kernel code that there is not such kind of limit, is it right? Is it the kernel responsible of taking down the controller to the first slot when the dma reserved memory is exhausted (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but I'm missing some details. >> I suppose that the issue on pccard32 >> hardware is not yet solved. > > Which issue? The one we are talking about, reported by Larry for some pccard32 boards where the opensource firmware crashes. We did several testing with a few 4306 pccard32s the first time Larry reported the problem but unfortunately that hardware has different problems and crashes also with the original firmware. > This crash does _not_ happen with proprietary firmware. > The only way dev->fw.rev could crash is by dev being NULL. Got it! Many thanks, -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: Improved opensource firmware
On Jul 24, 2009, at 1:24 AM, Larry Finger wrote: > Francesco Gringoli wrote: >> On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: >> >>> Francesco Gringoli wrote: >>>> 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. >>> >>> Francesco, >>> >>> The system ran about 30 minutes, then crashed. I missed the first >>> oops, but caught a kernel panic with formal traceback on my i386 >>> system: > > I had a kernel panic while testing the open firmware on a BCM4312 > 802.11abg model (rev 01). The b/g section is just like a BCM4311/1. I > was not watching the error console, so I have no dump information, but > will do that next. > > Larry Hi Larry, Last time (it was February I believe) I didn't buy anything because I was involved in other projects. So again I ask you if I can place an order for this item http://cgi.ebay.com/HP-PCI-E-Broadcom-4312-wifi-card-generation-of-4311_W0QQitemZ320388697319QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item4a98a78ce7&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1234%7C293%3A1%7C294%3A50#ht_2507wt_1012 I hope the link is ok, otherwise you can get the picture from here http://www.ing.unibs.it/~gringoli/4312.png Tell me it's ok, I will order immediately, without the board I can't debug. Many thanks, -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: Improved opensource firmware
On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: > On Thursday 23 July 2009 04:05:17 Larry Finger wrote: >> Francesco Gringoli wrote: >>> 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. >> >> Francesco, >> >> The system ran about 30 minutes, then crashed. I missed the first >> oops, but caught a kernel panic with formal traceback on my i386 >> system: >> >> b43_dma_handle_txstatus + 0x1ee/0x2fa >> b43_handle_txstatus + 0x45/0x52 >> >> The call in b43_dma_handle_status is at line 1405: >> >> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, >> 1); >> >> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to >> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the >> oops. > > How is that possible? Is the firmware clobbering random memory? I don't think that the value was modified by the firmware. It cannot poke values into host memory ;-) I suppose that the issue on pccard32 hardware is not yet solved. I will get a closer look at how the overflow condition should be handled correctly when reporting txstatus to host. 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: Improved opensource firmware
On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: > Francesco Gringoli wrote: >> 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. > > Francesco, > > The system ran about 30 minutes, then crashed. I missed the first > oops, but caught a kernel panic with formal traceback on my i386 > system: > > b43_dma_handle_txstatus + 0x1ee/0x2fa > b43_handle_txstatus + 0x45/0x52 > > The call in b43_dma_handle_status is at line 1405: > > unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > 1); > > The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the > oops. > > As usual, I was running an infinite loop of tcpperf in one console and > a flood ping in a second. > > Larry Hi Larry, Many many thanks. As I focussed almost only on the firmware side during these last months, I forgot to upgrade the kernel :-) . Which version have you used to do the test? Are you still using the PCcard32 (rev11/a)? I will try this summer to replicate precisely your setup. I also think it is time to use the support provided by Michael for telling the kernel which features are present. 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: b43 Hostap Performance
On Apr 10, 2009, at 2:02 PM, Gábor Stefanik wrote: > On Fri, Apr 10, 2009 at 12:28 AM, Francesco Gringoli > wrote: >> >> > > Can you please release the patch you used to transmit frames using b43 > directly, with a complete bypass of the stack? Also, what results do > you get if you instead try to use mac80211's radiotap injection > feature (which bypasses most, but not all of mac80211)? Hi Gábor, download the patch from http://www.ing.unibs.it/~gringoli/inject.tar.gz The patch is for 2.6.29-rc2-wl, I include example code. Please note that this patch slightly breaks the checking mechanisms implemented in mac80211 (removes the AP association check). You can inject anything you want controlling if the frame should wait for an ack or not, injection speed etc directly from the example code. Card should not be configured in monitor mode, I never tested it in such configuration. With minor modifications it can be applied to the compat-wireless directory from latest kamikaze, example code compiles with the toolchain with no modification. Cheers, -FG > > > Thanks, > Gábor > > -- > Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ 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: 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
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 9, 2009, at 11:56 PM, Michael Buesch wrote: > On Thursday 09 April 2009 23:47:25 Francesco Gringoli wrote: >> >> 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. > > 4318 is good enough for STA mode, but in AP mode it doesn't work > correctly, because > it simply loses too many packets. So it loses important management > frames, etc... . > If you limit the TX rate to 24M it becomes usable, however. > 4306 is _much_ better in AP mode. 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"? The only difference between station and AP mode AFAIK is that AP mode honors the TBTT condition and transmit the beacon when a beacon is needed. I say honor since that condition and the other about beacon needed are raised also in station mode but they are not handled. I'm confused. > > > 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 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? -Francesco > > > -- > 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: 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
Re: [PATCH, RFC] b44: Add fw capabilities
On Apr 9, 2009, at 11:05 PM, Lorenzo Nava wrote: > Hi, > > I think that Francesco agrees with me, so 0x42 is ok for firmware > capabilities. It's ok for me. -FG > > > Cheers, > > Lorenzo > > On Apr 9, 2009, at 1:26 PM, Michael Buesch wrote: > >> On Thursday 09 April 2009 12:36:42 Francesco Gringoli wrote: >>> On Apr 9, 2009, at 12:18 PM, Michael Buesch wrote: >>> >>>> On Wednesday 08 April 2009 02:11:16 Michael Buesch wrote: >>>>> Completely untested patch to implement firmware capabilities >>>>> and automagic QoS-disabling. >>>>> >>>> >>>> So could somebody who uses opensource fw test this? >>>> >>>> Module parameter qos=0 should not be needed anymore. So please test >>>> opensource fw >>>> with qos=1. >>> Hi Michael, >>> >>> cool! These are excerpts from dmesg. All the times connectivity >>> was ok. >> >> Ok nice. >> If you guys think 0x42 still is a good SHM offset, I'll submit it >> upstream. >> >> -- >> 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: [PATCH, RFC] b44: Add fw capabilities
gt;>
>> -hw->queues = b43_modparam_qos ? 4 : 1;
>> +hw->queues = modparam_qos ? 4 : 1;
>> +wl->mac80211_initially_registered_queues = hw->queues;
>> hw->max_rates = 2;
>> SET_IEEE80211_DEV(hw, dev->dev);
>> if (is_valid_ether_addr(sprom->et1mac))
>> @@ -4791,9 +4822,7 @@ static int b43_wireless_init(struct ssb_
>> else
>> SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
>>
>> -/* Get and initialize struct b43_wl */
>> -wl = hw_to_b43_wl(hw);
>> -memset(wl, 0, sizeof(*wl));
>> +/* Initialize struct b43_wl */
>> wl->hw = hw;
>> spin_lock_init(&wl->irq_lock);
>> rwlock_init(&wl->tx_lock);
>> @@ -4859,8 +4888,13 @@ static void b43_remove(struct ssb_device
>> cancel_work_sync(&wldev->restart_work);
>>
>> B43_WARN_ON(!wl);
>> -if (wl->current_dev == wldev)
>> +if (wl->current_dev == wldev) {
>> +/* Restore the queues count before unregistering, because
>> firmware detect
>> + * might have modified it. Restoring is important, so the
>> networking
>> + * stack can properly free resources. */
>> + wl->hw->queues = wl->mac80211_initially_registered_queues;
>> ieee80211_unregister_hw(wl->hw);
>> +}
>>
>> b43_one_core_detach(dev);
>>
>> Index: wireless-testing/drivers/net/wireless/b43/main.h
>> ===
>> --- wireless-testing.orig/drivers/net/wireless/b43/main.h
>> 2009-04-08 01:53:15.0 +0200
>> +++ wireless-testing/drivers/net/wireless/b43/main.h 2009-04-08
>> 01:53:20.0 +0200
>> @@ -39,7 +39,6 @@
>> #define PAD_BYTES(nr_bytes) P4D_BYTES( __LINE__ , (nr_bytes))
>>
>>
>> -extern int b43_modparam_qos;
>> extern int b43_modparam_verbose;
>>
>> /* Logmessage verbosity levels. Update the b43_modparam_verbose
>> helptext, if
>> Index: wireless-testing/drivers/net/wireless/b43/pio.c
>> ===
>> --- 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: firmware capabilities
On Apr 6, 2009, at 6:00 PM, Michael Buesch wrote: > I'd like to ask you guys to look for an unused u32 field for use as > firmware > capabilities field. > > This will be used by the driver to check whether the fw supports a > feature or not (QoS, crypto, etc...). > The field needs to be unused, so it defaults to all-zero even in > older released versions. > > Please tell me the SHM offset (byte or word offset). Hi Michael, I will check tomorrow with all ucodexx for a shm location that is never accessed. 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 Apr 5, 2009, at 8:58 PM, Michael Buesch wrote:
> On Sunday 05 April 2009 20:01:22 Francesco Gringoli wrote:
>> On Mar 30, 2009, at 11:35 PM, Francesco Gringoli wrote:
>>
>>>
>>> On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:
>>>
>>>>
Hi Michael,
>
> I think this really is completely getting overengineered by now.
>
> I'm not going to apply such a patch unless you tell me why it's
> needed.
> Having such an incredible mechanism for an absolute corner case that
> happens
> once in a billion frames but doesn't harm anybody is not really
> acceptable.
No problem :-) I simply sent the patch I'm using in my test
environment where I get this behavior for the 0.1% of the received
frames when FCSFAIL is set. Note that here we collect traces for
experiments with 802.11 protocol, so we need this kind of patches.
I understand that very few of us are doing such kind of experiments
and users are not, I simply sent a comment about these devices. It may
improve knowledge about them.
Cheers,
-FG
>
>
> If you have FCSFAIL set, you're expected to receive crap. It's as
> simple as that.
> If you don't want crap, don't set the bit.
>
>
>> 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
>> #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 mismatch, setting
>> FCSFAIL
>> and
>> keeping frame (" \
>> +"%02X %02X %02X %02X padding = %d, len = %d)\n",
>> +plcp_data[0],
>> +plcp_data[1],
>> +plcp_data[2],
>> +plcp_data[3],
>> +padding,
>> +
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
>> Signed-off-by: Michael Buesch
>>
>> ---
>>
>> 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
#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;
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
> Signed-off-by: Michael Buesch
>
> ---
>
> 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
t;
> - rxhdr = (struct b43_rxhdr_fw4 *)(skb->data);
> - rxhdr->frame_len = 0;
> -
> return 0;
> }
>
> @@ -1489,6 +1509,15 @@ static void dma_rx(struct b43_dmaring *r
> goto drop;
> }
> }
> + 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;
> + }
> 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: fix b43_plcp_get_bitrate_idx_ofdm return type
On Mar 26, 2009, at 5:44 PM, Michael Buesch wrote:
> On Tuesday 24 March 2009 19:57:33 Francesco Gringoli wrote:
>> The bad thing is that sometimes a bad alignment is not resolved in a
>> rate_idx = -1 as the first byte of the plcp (which is not actually
>> the
>> first since the pad was wrong) is mistakenly resolved to a valid
>> encoding.
>
> I think this case is extremely rare and this is nothing we need to
> worry about.
> A checksum is no guarantee either that the frame really is not
> corrupt. So
> we already live with the assumption that there may be a bad frame of
> one
> million or something like that.
Hi Michael,
I spent more time debugging this issue. I found something interesting:
when we ask the firmware to pass corrupted frames, it can happen
(actually it happens frequently if traffic is high) that the firmware
detects something was received even if the internal rx buffer is
completely empty while SPR_RXE_FRAMELEN is > 0. In this case, the
firmware jumps to push_frame_into_fifo anyway and raises a rx irq. The
kernel handles this dma event and b43 thinks that a frame has been
received, instead the dma buffer is filled with random data (sometimes
with data of a previous packet), at the end a skb with something that
was not a packet is passed to mac80211. This happens with both
original and open firmwares.
I wrote this patch so that b43 can understand if something was
actually transferred during the dma event: basically, it always fills
the plcp part of the dma buffer with impossible data, so if this
impossible data is still there after dma event this means that nothing
was transferred. This avoid fake packets to be feed into the rx queue
(e.g., for those interested in capturing corrupted frames).
Cheers,
-FG
Signed-off-by: Francesco Gringoli
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===
--- drivers/net/wireless/b43/dma.c 2009-03-26 19:31:37.0
+0100
+++ drivers/net/wireless/b43/dma.c 2009-03-26 20:08:34.0
+0100
@@ -568,6 +568,7 @@
skb = __dev_alloc_skb(ring->rx_buffersize, gfp_flags);
if (unlikely(!skb))
return -ENOMEM;
+ memset(skb->data + ring->frameoffset, 0xff, 8);
dmaaddr = map_descbuffer(ring, skb->data, ring-
>rx_buffersize, 0);
if (b43_dma_mapping_error(ring, dmaaddr, ring->rx_buffersize,
0)) {
/* ugh. try to realloc in zone_dma */
@@ -578,6 +579,7 @@
skb = __dev_alloc_skb(ring->rx_buffersize, gfp_flags);
if (unlikely(!skb))
return -ENOMEM;
+ memset(skb->data + ring->frameoffset, 0xff, 8);
dmaaddr = map_descbuffer(ring, skb->data,
ring->rx_buffersize, 0);
if (b43_dma_mapping_error(ring, dmaaddr, ring-
>rx_buffersize, 0)) {
--- drivers/net/wireless/b43/xmit.c 2009-03-26 19:41:53.0
+0100
+++ drivers/net/wireless/b43/xmit.c 2009-03-26 20:08:16.0
+0100
@@ -527,6 +527,7 @@
u16 chanid;
u16 phytype;
int padding;
+ u8 *plcp_check;
memset(&status, 0, sizeof(status));
@@ -560,6 +561,17 @@
goto drop;
}
plcp = (struct b43_plcp_hdr6 *)(skb->data + padding);
+ plcp_check = (u8*) plcp;
+ if(plcp_check[0] == 0xff &&
+ plcp_check[1] == 0xff &&
+ plcp_check[2] == 0xff &&
+ plcp_check[3] == 0xff &&
+ plcp_check[4] == 0xff &&
+ plcp_check[5] == 0xff) {
+ b43dbg(dev->wl, "RX: no packet received?\n");
+ goto drop;
+ }
+
skb_pull(skb, sizeof(struct b43_plcp_hdr6) + padding);
/* The skb contains the Wireless Header + payload data now */
if (unlikely(skb->len < (2 + 2 + 6 /*minimum hdr */ +
FCS_LEN))) {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: fix b43_plcp_get_bitrate_idx_ofdm return type
On Mar 22, 2009, at 7:18 PM, Larry Finger wrote: > Lorenzo Nava wrote: >> Once again... >> >> Reported-by: Lorenzo Nava >> Signed-off-by: Lorenzo Nava > Cc: Stable [2.6.28, 2.6.27] > > Sorry to join this party late, but the line above should be added as > this bug > goes back at least to 2.6.27 and should be applied to stable. I > didn't check any > further. > > > Larry > Larry, Michael, I checked within the firmware to understand what happens when the rate_idx is not successfully resolved. First of all, this never happens with FCS good frames, at least in my experiments. When FCS is wrong, instead, I noticed that padding could be set to 2 by the firmware (by setting bit 0x20 of SPR_RXE_FIFOCTL1) even if it is not necessary, e.g., an error forces both from_ds and to_ds bits to 1, so the firmware thinks the frame is a WDS one, while it is not. This wrong setting, however, is not responsible for the wrong rate_idx. When a frame is wrong, in fact, we can face two scenarios: A)- some modulated symbols were not correctly decoded but the packet is preserved (of course its content is wrong) B)- what we think is a frame in the rx buffer is not a frame but it is a halved frame (reception stopped before packet ended), or it is a mix of multiple frames on the air In the first scenario the length of the frame (basically, the SPR_RXE_FRAMELEN value that was used by the firmware to push the frame to the host) is consistent with the length reported inside the plcp, that is always correct (the plcp) as it is protected on its own and we do discard plcp bad frames. In this case I _NEVER_ experienced a mismatch between the padding advertised by the firmware with that I computed by checking the first eight bytes as said before. In the second case, instead, I saw that sometimes the reported padding is wrong, e.g., a pad = 2 is reported while the plcp begins on the first byte, or viceversa. The conclusion is that Michael is right, there is a bug in the rx engine, and this bug causes a mis-alignment of the frame pushed through the dma, although this issue is limited to wrong frames of type B. The bad thing is that sometimes a bad alignment is not resolved in a rate_idx = -1 as the first byte of the plcp (which is not actually the first since the pad was wrong) is mistakenly resolved to a valid encoding. This case can be funny since the determined speed could be wrong. Cheers, -FG > > > ___ > 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: [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
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 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 > > --- > > 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->n
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: 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 22, 2009, at 2:42 PM, Gábor Stefanik wrote: > On Sun, Feb 22, 2009 at 1:22 PM, Francesco Gringoli > wrote: >> 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 >> > > Does OpenFWWF or Michael's openfw honor KEEP_BAD? openfwwf does honor the bit. Cheers, -FG > > > -- > Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) --- 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: 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: 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(st
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: Problems sniffing custom frames with b43
On Feb 13, 2009, at 11:35 PM, [ tR3nt R32n0r ] wrote: Hi all, I'm using an Asus card WL-138G v2 PCI with b43 driver and a 2.6.27 kernel version. Tryng to sniff packets with this card set in monitor mode I found that every packet in the air was recognized via Wireshark except the ones I made and sent with pcap library tools froma another peer. The packets are really sent because they can be read from the media with another cards such as D-link 11n usb or Atheros mini PCI, but it seems like there is somewhere where the incomming packets are filtered. I don't know how to solve this problem. Maybe it is because the driver only recognizes "standard" frames such as the ones made for management, but I don't know it for sure. My frames include the 802.11 header describing the frame as management frame type, using a non defined subtype. Can anybody help me? Hi, could you please attach the wireshark dump of the packet as received by the atheros board? Start from the 802.11 header. Cheers, -FG Thanks! ___ 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: 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 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 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 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 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 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
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 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
ad-hoc mode implementation
Hello, I began testing the opensource firmware on b43 when running ad-hoc mode and I faced a strange problem that drove me to investigate about how ad-hoc mode is implemented inside the wireless stack. Note that what follows holds for both Broadcom original firmware and opensource one, however I did all these tests switching back to original BCM firmware. It turned out that Apple Macs with 4328 hardware (bot a/b/g and n) running different version of OSX never succeed in joining ad-hoc networks initiated by b43 while they can join without problems ad-hoc networks run by ath5k (with initiated or run I mean "the first node that is configured with that SSID"). I attach a complete description of the tests at the end of this message. I then captured some traffic and it seems that b43 never sends beacon when initiating ad-hoc networks, it just sends probes to itself and responds to broadcast probe requests. Note that ath5k instead sends beacons as long as it is the first node. Probably I'm missing something, so just responding to broadcast probes could be a correct alternative procedure to advertise ad-hoc network, however this seems to be the only difference to explain the different behavior of newer Apple Macs when joining ath5k or b43 ad-hoc initiated networks. Please note that if I invert roles (ad-hoc initiated by those Apple Macs, b43 joining the network) everything is fine, so this is not an issue involving send and receive operations, nodes do not have communication problems. Has anyone ever experienced such issues? Is it correct to not send beacon when starting an ad-hoc network? I did some tests and OSX does send beacon when initiating an ad-hoc network (as ath5k does). Cheers, -FG - testbed scenarios When I initiate an ad-hoc network on a Linux PC with a 4306 card, I can't join it using any of my Apple Macs equipped with BCM hardware. I tried two different Apple, one is a new MacBook Pro with 4328 BCM N- PHY, the other is a two years old iMac 17 with a a/b/g 4328 BCM hardware. The Kernel I used on the x86 PC was 2.6.29-rc2-wl, the firmware was the original Broadcom ucode5, I did not use encryption. I did extensive testing but I never succeeded. I then tried the same setup, using this time a 4318 card to initiate the ad-hoc network on the Linux box, and I got the same behavior. Finally I repeated the experiment this time initiating the ad-hoc network with a Linksys WRT54GL (BCM 4320), same result, the two Apple Macs never joined the network, they reported a generic error and nothing more. Please note that if I repeat the experiments using a MacBook Pro with Atheros hardware everything works fine. Also all other Linux PC I have do not have problems in joining these b43-run ad-hoc networks independently of the kind of Atheros or BCM hardware they use. ___ 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: 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 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, 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 strange thing is that the way b43 is interfaced to the firmware, when hw encryption is not activated, does not change switching from 351 to 410 version apart for the txheader layout: however we modified that layout according to definitions in xmit.h. Is this correct? If this hold I really can not understand why r5.1 had problems and r5.0 not in your setup. I would have supposed that given r5.1 has problems, the same can arise also on r5.0. Thanks, -FG Tests description: we did the following couple of tests - downloaded 1GB through TCP while sending 1.6GB of UDP like traffic through a raw socket, 10 ping/s - sent 10GBYTE by injecting packets composed in userspace through a ioctl we attached to mac80211 stack: packets are sent one after another without ACKs, separated by just a SIFS and encoded at 54Mb/s (this is a very small firmware hack that reprograms next transmission opportunity 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 ___ 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
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
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
Re: 4318 Question Frame Check Sequence Errors
On Jan 26, 2009, at 10:17 PM, Tex wrote:
> I have been running some surveys with the Atheros and Broadcom
> Drivers.
> When viewing the frames from wireshark , while in monitor mode, I
> noticed that the Atheros driver is reporting FCS errors on some
> frames,
> but the Broadcom driver isn't, in the radiotap header. If I expand the
> frame and look at the FCS wireshark reports the frame as bad and shows
> what the CRC should be. I put printk's in pio_rx_frame() (see below)
> and
> noticed that the macstat is being reported as zero. Does this mean
> that
> the status is not being sent to the driver from the chip or
> firmware? Is
> there some way for me to configure it to report bad FCS frames?
When the flag B43_MACCTL_KEEP_BAD is enabled in the opmode of b43,
then the driver activates the corresponding flag in the mac control
high register so that the firmware is configured to report bad frames
to the host. However as soon as they are sent through dma, the b43
driver logs messages like "b43-phy5 debug: RX: Packet dropped" and
frames are not delivered to the upper layers. To investigate you can
try to enable that flag by modifying the basic configuration in
b43_adjust_opmode(struct b43_wldev *dev) defined in main.c.
Cheers,
-FG
>
> macstat = le32_to_cpu(rxhdr.mac_status);
> printk (KERN_DEBUG "pio_rx_frame macstat is %x\n",
> macstat);
> if (macstat & B43_RX_MAC_FCSERR) {
> if (!(q->dev->wl->filter_flags & FIF_FCSFAIL)) {
> /* Drop frames with failed FCS. */
> err_msg = "Frame FCS error";
> goto rx_error;
> }
>
> b43_op_configure filter has the following flags set:
>*fflags &= FIF_PROMISC_IN_BSS |
> FIF_ALLMULTI |
> FIF_FCSFAIL |
> FIF_PLCPFAIL |
> FIF_CONTROL |
> FIF_OTHER_BSS |
> FIF_BCN_PRBRESP_PROMISC;
>
>changed &= FIF_PROMISC_IN_BSS |
> FIF_ALLMULTI |
> FIF_FCSFAIL |
> FIF_PLCPFAIL |
> FIF_CONTROL |
> FIF_OTHER_BSS |
> FIF_BCN_PRBRESP_PROMISC;
>
>
>
>
> Thanks much
> Tex
>
> ___
> 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: 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
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: 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 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 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 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
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: 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: 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 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: [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
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: [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
Re: b43 open-firmware new snapshot
>> This firmware does _only_ work on wireless core revisions 5, 6, 7, >> 8 or 10. > > There are reports of it working on rev.9 cores. Is that possible? > (Resend of previous mail to the list.) Hi there, I get this Jun 18 16:43:51 b43 kernel: [ 21.152097] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) Jun 18 16:43:51 b43 kernel: [ 21.152113] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) Jun 18 16:43:51 b43 kernel: [ 21.152122] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) Jun 18 16:43:51 b43 kernel: [ 21.152132] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) it should be a rev.9 core. Well, I got it running in monitor mode, I clear saw tcpdump doing its work. But I think Michael is right, just after a while it crashed: before doing that syslog filled up with [ 1213.209871] [ cut here ] [ 1213.209878] WARNING: at drivers/net/wireless/b43/xmit.c:49 b43_rx +0x1a5/0x630 [b43]() [ 1213.209880] Modules linked in: b43 rfkill_input arc4 ecb crypto_blkcipher rfkill mac80211 cfg80211 input_polldev af_packet radeon drm speedstep_lib cpufreq_stats cpufreq_ondemand freq_table cpufreq_powersave cpufreq_userspace cpufreq_conservative container sbs sbshc loop serio_raw psmouse pcspkr usbhid hid ssb battery asus_laptop led_class ac button sis_agp agpgart evdev xfs ide_disk ide_cd_mod cdrom ata_generic pata_sis libata dock floppy skge ehci_hcd ohci_hcd usbcore sis5513 ide_core thermal processor fan fuse [last unloaded: b43] [ 1213.209926] Pid: 0, comm: swapper Tainted: GW 2.6.26-rc6-wl #1 [ 1213.209931] [] warn_on_slowpath+0x5f/0x90 [ 1213.209947] [] enqueue_task+0x12/0x30 [ 1213.209955] [] activate_task+0x24/0x40 [ 1213.209963] [] __wake_up_common+0x3e/0x70 [ 1213.209973] [] sock_def_readable+0x41/0x50 [ 1213.209980] [] sock_queue_rcv_skb+0xa1/0xe0 [ 1213.209986] [] udp_queue_rcv_skb+0xb0/0x280 [ 1213.209997] [] ssb_pci_read32+0x1c/0x60 [ssb] [ 1213.210010] [] __slab_alloc+0xa2/0x410 [ 1213.210016] [] __ieee80211_rx_handle_packet+0x5e0/0x7b0 [mac80211] [ 1213.210038] [] b43_rx+0x1a5/0x630 [b43] [ 1213.210050] [] b43_chip_init+0xa10/0xa20 [b43] [ 1213.210059] [] op32_fill_descriptor+0x45/0xe0 [b43] [ 1213.210077] [] b43_dma_rx+0x16e/0x400 [b43] [ 1213.210097] [] b43_interrupt_tasklet+0x378/0x910 [b43] [ 1213.210106] [] enqueue_task+0x12/0x30 [ 1213.210111] [] activate_task+0x24/0x40 [ 1213.210126] [] tasklet_action+0x34/0x70 [ 1213.210131] [] __do_softirq+0x42/0x90 [ 1213.210136] [] do_softirq+0x27/0x30 [ 1213.210139] [] irq_exit+0x45/0x60 [ 1213.210142] [] do_IRQ+0x39/0x70 [ 1213.210151] [] common_interrupt+0x23/0x30 [ 1213.210162] [] acpi_idle_enter_simple+0x16e/0x1db [processor] [ 1213.210177] [] acpi_idle_enter_bm+0xb7/0x2a2 [processor] [ 1213.210187] [] cpuidle_idle_call+0x68/0xa0 [ 1213.210193] [] cpuidle_idle_call+0x0/0xa0 [ 1213.210197] [] cpu_idle+0x24/0x70 [ 1213.210206] === [ 1213.210209] ---[ end trace 4d6796847711ea43 ]--- repeated hundreds of time. I'm using wireless-testing (git-pulled this morning) e latest firmware image. I succeeded to find three cards and they all are rev.9! Regards, FG ___ 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
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 there, > > Why are you interested in this? I mean, you have been provided with > the > complete instruction set and an almost complete list of registers. > You have I know since 30 minutes ago about the existence of the assembler/ disassembler!! I'm going to test it. > been provided with a driver which can give you ucode register > values in > realtime. What else do you need? To me, it looks like you want > other people > to do your homework. > Thank you, FG ___ 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 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
